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ABSTRACT 


The  Telecommunications  Emergency  Decision  Support  System  (TEDSS)  was  developed 
by  the  National  Communications  System  (NCS)  to  assist  in  the  management  of  national 
communication  assets  during  times  of  emergency.  TEDSS  is  currently  approaching  the  end  of 
its  system  life,  and  is  only  marginally  capable  of  meeting  existing  and  future  requirements. 
The  personal  computer-based  system  uses  a  structured  menu-oriented  interface  developed 
within  an  INGRES  database  management  system  application  environment.  This  system 
provides  predefmed  queries  and  menus  which  minimize  the  amount  of  decision  support 
provided  for  emergency  management. 

This  thesis  reviews  the  current  operational  capabilities  of  TEDSS  and  the  emergency 
decision  making  environment  in  which  it  operates.  It  proposes  a  conceptual  shift  of  TEDSS 
from  its  current  textually-oriented  information  system  to  a  graphicaUy-oriented  Tactical 
Decision  Aid  (TDA).  The  proposed  system  would  employ  a  Graphical  User  Interface  (GUI) 
providing  a  standard  interface  to  a  Geographical  Information  System  (GIS).  The  GIS  would 
provide  a  map-based  enviroiunent  in  which  the  user  manipulates  data  and  models.  Software 
and  hardware  issues  relating  to  the  development  of  a  TDA-based  TEDSS  are  discussed. 
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I.  INTRODUCTION 


The  Telecommunications  Emergency  Decision  Suppon  System  (TEDSS)  is  an 
automation  tool  which  has  been  developed  by  the  Federal  Government  to  assist  in  the 
management  of  communications  assets  during  times  of  national  emergencies.  The  system 
was  "designed  to  provide  timely,  accurate,  and  relevant  information  concerning 
telecommunications  capabilities."  (Short  and  Bockenek,  1989,  p.  1).  It  supports  the 
National  Communications  System  (NCS)  Headquarters  and  Regional  components 
Emergency  Management  Teams  (EMT)  tasked  with  maintaining  viable  functioning 
communication  links  across  the  country  during  times  of  emergency.  The  existing  system 
provides  limited  support  for  the  current  mission  in  the  form  of  a  database-oriented  system. 
The  system  provides  data  retrieval  but  very  little  decision  support.  As  the  amount  of 
electronic  data  increases  and  our  dependence  on  the  ability  to  maintain  those 
communications  channels  becomes  more  critical,  TEDSS,  as  currently  configured,  will  be 
hard  pressed  to  support  the  future  effective  management  of  restoring  communications. 
(Short  and  Bockenek,  1989,  p.  1) 

A.  TEDSS  OBJECTIVE 

The  TEDSS  is  designed  to  assist  in  the  management  of  three  general  types  of 
communication  problems: 

1 .  Localized  regional  emergencies  such  as  floods  and  other  natural  disasters. 
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2.  Emergencies  affecting  multiple  regions  of  the  nation  that  require  national-level 
coordination,  e.g.,  Three  Mile  Island  incident. 

3.  Nationwide  emergencies  such  as  a  potential  nuclear  attack.  (Short  and  Bockenek, 
1989,  p.  3) 

The  NCS  has  originally  separated  TEDSS  responsibilities  into  three  op)erational 
domains: 

1.  National  Level  -  to  enable  the  Office  of  the  Manager,  National  Communication 
Services,  to  monitor,  coordinate  and  control  telecommunications  resources  during  a 
national  emergency. 

2.  Regionally-Deployed  Component  -  to  aid  in  monitoring  regional  emergencies  and 
coordinating  actions  affecting  multiple  regions  of  the  nation. 

3.  Regional-Level  Component  -  to  manage  the  information  needed  to  resolve  local 
emergencies  without  the  direct  involvement  of  the  national  level  of  NCS.  (Booz,  Allen 
and  Hamilton,  Deployment  Plan,  1988,  p.  2) 

Short  and  Bockenek’s  thesis  (1989)  and  the  Booz,  Allen  and  Hamilton’s 
Deployment  Plan  (1988)  provide  additional  descriptions  of  the  original  delineation  of 
component  responsibilities.  While  the  system  initially  was  physically  configured  to  match 
these  three  areas  of  responsibilities,  the  rapid  development  of  inexp)ensive  and  more 
powerful  computing  hardware  and  software  has  blurred  the  distinctions  between  the 
national  and  regional  systems.  Presently  the  primary  difference  between  the  components 
is  in  administrative  control  of  data  update  capabilit'es.  It  appears  that  the  MicroVAX 
mini-computer  which  has  served  to  manage  the  TEDSS  regional/national  databases  is 
being  phased  out,  and  all  TEDSS  functions  will  be  maintained  on  the  deployable  portable 
machine. 
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B.  TEDSS  GENEALOGY* 


Tlie  NCS  was  directed  by  executive  order  to  prepare  plans  and  coordinate  systems 
to  establish  and  maintain  communications  during  times  of  national  emergencies 
(Reinman,  1984,  p.  12).  After  a  national  telecommunications  exercise  was  conducted  in 
1982,  subsequent  review  of  the  exercise  identified  a  need  for  an  automated  decision 
support  system  to  assist  in  the  management  and  tracking  of  telecommunications  assets 
(Short  and  Bockenek,  1989,  p.  1).  In  an  effort  to  manage  the  information  about  various 
communications  assets  and  points  of  contact  a  microcomputer-based  Fly  Away 
Management  Information  System  (FAMIS)  was  developed  in  1983  (Lyons,  1986,  p.  2). 

The  FAMIS  system,  while  an  improvement  in  emergency  information  management, 
was  limited  in  providing  effective  support  in  times  of  crisis.  The  NCS  contracted  for 
several  smdies  and  development  efforts  to  move  the  FAMIS  system  to  a  mini-computer 
and  micro-computer  implementation.  This  revised  implementation  of  FAMIS  was  called 
the  Emergency  Preparedness  Management  Information  System  (EPMIS).  The  EPMIS 
system  reshaped  the  data  management  capabilities  around  a  database  management  system 
and  added  some  additional  functionality  to  FAMIS.  However  it  still  maintzuned  a 
structured  menu-oriented  system  and  a  restrictive  data  manipulation  scheme. 


'In  1990,  the  system  name  became  Telecommunications  Emergency  Decision  Support 
System  (TEDSS),  however  the  system  was  originally  developed  under  the  name  O'  the 
Fly  Away  Management  Information  System  (FAMIS)  which  evolved  into  the  Emergency 
Preparedness  Management  Information  System  (EPMIS).  During  this  thesis,  all 
references  to  the  system  will  be  as  TEDSS. 


3 


During  a  series  of  enhancements  to  EPMIS,  the  system  name  was  eventually 
changed  to  the  Telecommunications  Emergency  Decision  Support  System  (TEDSS).  The 
current  version  of  TEDSS,  version  6.0,  provides  some  graphical  presentation  tools  but  still 
maintains  a  primarily  text -based  information  system.  Chapter  n  will  address  the  present 
functional  capability  of  the  TEDSS  system  in  more  detail. 

C.  SCOPE  OF  THESIS 

TEDSS  is  approaching  a  crossroads  in  its  system  life.  The  current  implementation 
has  several  limitations  that  are  impeding  its  present  operation  and  may  complicate  future 
enhancements  as  the  system  continues  to  evolve.  This  thesis  will  review  the  current  state 
of  the  TEDSS  system  and  its  present  functional  capabilities.  It  will  then  address  relevant 
issues  involving  a  complete  reassessment  of  the  current  TEDSS  implementation.  The 
purpose  of  the  thesis  is  to  provide  a  revised  framework  for  the  TEDSS  system  hardware 
and  software  architecture.  The  objective  is  to  envision  an  enhanced  platform  which  not 
only  suppons  emergency  management  decisions  better  today,  but  will  also  provide  a 
suitable  migration  path  for  TEDSS  growth  into  the  future. 

D.  METHODOLOGY 

The  NCS  believes  that  TEDSS  currently  possesses  the  basic  functionality  required 
to  support  its  mission.  However.  TEDSS  performance,  operational  costs,  and 
expendabilify  are  considered  lacking.  This  thesis  will  be  divided  into  two  sections.  The 
first  will  evaluate  the  existing  system  and  how  it  supports  the  decision  making  process, 
and  will  include: 


4 


1.  A  review  of  the  current  TEDSS  system  to  determine  the  current  fimctions  it  performs, 
and 

2.  An  investigation  of  the  emergency  and  tactical  decision  making  environment,  and 
development  of  a  proposed  system  to  overcome  existing  deficiencies  in  TEDSS. 

The  second  section  will  detail  the  proposed  system  to  enhance  TEDSS  ability  to 

support  the  decision  making  process,  and  will  include: 

3.  A  discussion  of  the  implications  of  the  proposed  system,  and  how  it  will  affect  the 
TEDSS  decision  making  environment  and  its  users, 

4.  An  explanation  of  the  primary  components’  utilization  in  the  proposed  system,  and 

5.  Identification  of  critical  developmental  issues  that  must  be  addressed  prior  to 
implementation  of  future  TEDSS  revisions. 


E.  THESIS  STRUCTURE 

The  remainder  of  the  thesis  will  be  structured  as  follows. 

Chapter  II  analyzes  and  reviews  the  current  TEDSS  hardware  and  software 
configuration. 

Chapter  in  analyzes  TEDSS  in  the  context  of  tactical  decision  environments  and 
systems  to  support  NCS  decision  making  and  proposes  a  TEDSS  block  architecture 
consistent  with  this  concept. 

Chi^ter  IV  discusses  the  capabilities  and  implications  of  utilizing  a  Graphic  User 
Interface  (GUI)  and  Geographic  Information  System  (GIS)  as  integral  components  of 
TEDSS. 
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Chapter  V  discusses  software  considerations  in  the  future  development  of  TEDSS 
to  both  decrease  system  maintenance  cost  and  provide  for  a  baseline  system  that  will 
serve  as  an  expanding  platform  for  emerging  technology. 

Chapter  VI  addresses  the  unique  operational  issues  and  requirements  for  the  TEDSS, 
and  the  tradeoffs  that  should  be  addressed  in  fiiture  TEDSS  hardware  components. 

Chapter  Vn  concludes  the  thesis  by  reviewing  the  proposed  system,  summarizing 
issues  and  discussing  the  advantages  of  the  proposed  system  to  support  the  evolution  of 
TEDSS  into  the  next  century. 

F.  LIMITATIONS 

The  primary  limitation  to  this  thesis  has  been  determining  the  present  capabilities 
of  TEDSS  and  the  lack  of  current  or  detailed  documentation  of  the  system.  During  my 
site  visit  to  NCS,  the  current  model  of  TEDSS  was  not  available  for  review  because  of 
security  restrictions.  An  earlier  beta  version  was  available  which  provided  a  basic 
understanding  of  the  system  and  its  user  interface  but  did  not  implement  the  Mapinfo 
interface.  Much  of  the  information  on  the  use  and  capabilities  of  TEDSS  was  determined 
by  several  conversations  with  Major  Fran  School  at  NCS,  including  a  basic  understanding 
of  the  TEDSS  tactical  decision  making  environment. 
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n.  TEDSS  ENVIRONMENT 

The  Telecommunications  Emergency  Decision  Support  System  (TEDSS)  is  designed 
to  support  the  NCS  in  time  of  crisis,  and  like  most  information  systems,  is  evolutionary 
in  namre.  ITie  original  system  designed  in  the  early  1980’s  would  have  been  considered 
"state  of  the  art"  for  that  time.  However,  rapid  advances  in  computing  technology  and 
software  developments  have  overshadowed  the  relatively  limited  range  of  functions  which 
TEDSS  currently  performs.  The  present  TEDSS,  version  6.0,  is  significantly  more 
powerful  than  its  original  implementation  in  terms  of  raw  computing  power,  but  the 
system’s  functional  capabilities  and  data  access  tools  have  not  changed  significantly. 

The  current  TEDSS  is  composed  of  two  separate  hardware  platforms:  the  national 
and  regional  components  which  operate  on  MicroVAX  n  mini-computers,  and  the 
deployable  component  which  operates  on  portable  personal  computer  (PC).  Previously, 
the  TEDSS  database  had  been  maintained  on  the  national  component’s  MicroVAX  which 
updated  the  regional  components  which  in  turn  updated  the  deployable  component’s 
database.  It  appears  that  the  functions  of  the  MicroVAX  are  being  transferred  to  the 
deployable  component,  and  future  versions  of  the  TEDSS  (beyond  version  6.0)  will  no 
longer  utilize  the  MicroVAX. 

A.  HARDWARE 

The  TEDSS  requirement  of  portability  has  been  a  limiting  factor  in  some  decisions. 
The  present  system  utilizes  an  Intel  80386-based  portable  PC  which  requires  1 10  volts 
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AC  to  operate.  The  basic  system  contains  a  gas-plasma  style  display  and  detachable 
keyboard.  The  initial  system  goal  was  to  provide  all  required  capabilities  in  a  single  unit. 
However,  during  TEDSS  software  development,  a  larger  fixed  disk  storage  capacity  was 
required  than  could  be  internally  mounted.  To  provide  enough  storage  capacity  an 
external  removable  cartridge  hard  disk  storing  200  megabytes  of  information  was 
instaUed.  The  removable  cartridge  allows  the  replacement  or  removal  of  all  software 
from  the  TEDSS  system  in  a  few  minutes. 

Beginning  with  version  6.0  of  TEDSS,  a  DOS-based  mapping  package  and  color 
video  graphics  adapter  (VGA)  monitor  were  added  to  the  system.  It  is  assumed  that  the 
monitor  was  added  to  provide  better  image  resolution  and  easier  viewing,  and  not  because 
the  mapping  package  was  unable  to  support  the  system’s  internal  gas  plasma  display. 


B.  SOFTWARE 

The  TEDSS  deployable  software  suite  is  composed  of  three  distinct  component 
programs,  in  addition  to  the  custom  developed  software: 


1.  The  Operating  System:  Interactive  386/ix  UNIX.  Interactive’s  UNIX  suprports  all 
standard  UNIX  functions  and  the  disk  operating  system  (DOS)  for  the  personal 
computer  operating  under  UNIX,  wherein  DOS  applications  run  as  processes  under  the 
UNIX  operating  system. 

2.  Database  Management  System:  INGRES  relational  database  management  system  for 
the  UNIX  operating  system.  (Version  5.0/06). 

3.  Geographic  Information  System:  Mapinfo  operating  in  the  DOS  environment.  The 
Maplnfo  package  will  display  information  onto  regional  maps  and  plot  points  stored 
in  an  ASCII  file  or  external  database. 
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The  menuing  system  and  other  software  procedures  were  developed  using  EAGRES 
application  development  tools  and  the  C  programming  language.  The  use  of  a  proprietary 
package  (INGRES)  to  develop  and  control  the  user  interface  has  unnecessarily  constrained 
options  to  update  or  revise  TEDSS.  As  TEDSS  is  currently  implemented,  it  can  not 
operate  unless  INGRES  is  present. 

C.  PRESENT  USER  INTERFACE 

The  TEDSS  system  relies  on  a  menu-based  interface  which  allows  the  user  to  select 
from  different  views  of  the  information  within  the  database.  Figure  1  shows  the  TEDSS 
main  menu  as  displayed  in  the  Booz,  Allen  and  Hamilton  Regional  Component  Software 
Design  (1989)^.  Once  the  data  desired  is  selected,  some,  but  not  all,  menu  screens 
provide  an  option  to  display  the  selected  information  graphically  utilizing  the  Mfqjinfo 
package.  The  data  selected  in  the  menu  is  written  to  an  ASCII  text  file,  and  then 
displayed  on  a  map  of  the  area. 

Figure  2  provides  a  graphical  view  of  the  overall  menu  structure.  The  following 
is  a  short  summary  of  the  menu  options  (Booz,  Allen  and  Hamilton  Deployment  Plan, 
1988,  p.  16). 

1.  Emergency  Activation  Procedures 

The  Emergency  Activation  Procedures  menu  item  allows  the  user  to  select 
from  another  menu  to  retrieve  Emergency  Action  Documents,  determine  and  track  the 
Emergency  State  of  the  Nation,  and  generate  a  regional  emergency  recall  list. 

^This  is  the  latest  known  hardcopy  documentation  on  the  TEDSS  menu  schema. 
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TEDSS 
Main  Menu 

1.  Emergency  Activation  Procedures 

2.  Emergency  Points  of  Contact 

3.  Resource  Management 

4.  Damage  Assessment 

5.  Service  Requests 

6.  Communications 

7.  Exit 

Enter  Selection  : _ 

Help  (FI) 

Figure  1  TEDSS  Main  menu  screen 

2.  Emergency  Points  of  Contact 

The  Emergency  Points  of  Contact  menu  item  allows  the  user  to  update  or 
retrieve  from  an  address  and  telephone  database  of  critical  personnel. 

3.  Resource  Management 

Resource  Management  is  the  primary  module  in  the  current  TEDSS  system 
allowing  the  user  to  enter,  change  the  status  of,  or  monitor  several  different  resoiurce 
conditions.  There  are  two  menu  items:  resource  entry  and  monitor  resources. 
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Emergency 

1—  Emergency  Activation  Documents  (EAD) 

r-  Activation  — — 

^Emergency  State  of  the  Nation 

Procedures 

*—  Emergency  Recall  List 

Emergency 

—  Points  of  — — 

—  Queries 

Contact 

Main 

Resource 

f—  Enter  Resources 

Menu 

Management 

Monitor  Resources 

Damage 

p-  Enter  Damage 

Assessment 

T—  Execute  Damage 

^  Monitor  Damage 

Service 

Service  Requests 

Requests 

Facility  Requests 

Communications 

1  Telephone 

Messages 

Figure  2  TEDSS  menu  structure 


a.  Resource  Entry 

Additional  changes  to  existing  resources  are  manually  entered  via  a 
preprogrammed  form.  There  are  seven  types  of  resources  presently  monitored: 
personnel,  networks,  nodes,  links,  operations  centers,  asset  centers,  and  assets.  The 
following  list  is  a  short  description  of  the  resources  monitored  and  a  partial  list  of  the 
information  stored  within  the  database.  Short  and  Bockenek  (1989),  and  Booz,  Allen  and 
Hamilton’s  two  reports  Regional  Component  Software  Design  (1989)  and  Deployment 
Plan  (1988)  provide  additional  information  concerning  resource  definition,  database  de  sign 
and  screen  content. 
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1.  Personnel  -  status,  primary  and  emergency  locations.^ 

2.  Networks  -  network  name,  network  identification  (ID),  description,  control  center 
location  and  point  of  contact  (POC). 

3.  Nodes  -  nodes  within  a  network,  including  network  ID,  description,  location,  and  PCXT. 

4.  Links  -  the  links  between  two  nodes  on  a  network,  including  node  Ids,  description, 
priority  and  carrier. 

5.  Operation  Centers  -  information  on  the  operation  center  which  controls  a  network, 
including  network  ID,  description,  status,  and  POC. 

6.  Assets  -  communication  asset  including  a  description,  status,  location,  priority, 
mobility,  capabilities  and  POC. 

7.  Asset  Center  -  the  asset  center  assigned  to  a  resource  location  including  name, 
description,  location,  status  and  POC. 

b.  Monitor  Resources 

This  menu  item  allows  users  to  query  the  database  to  determine  the  status 
of  various  resources  according  to  predefined  criteria.  Users  may  query  by  network,  node, 
location,  status  and  other  key  fields.  However  they  are  restricted  by  the  menu  as  to 
which  selection  criteria  may  be  applied  to  each  resource.  The  queries  allow  the  user  to 
select  according  to  several  key  areas  but  do  not  aUow  any  boolean  search  criteria. 

As  currently  implemented,  a  boolean  search  to  determine  only  the  nodes 
within  the  states  of  California  and  Nevada  is  not  possible.  TEDSS  as  currently 
configured  only  allows  selections  on  the  state,  region,  or  national  geographical  areas.  To 
implement  this  search  would  require  selecting  all  nodes  in  the  region,  and  then  manually 

^Location  unless  otherwise  stated  is  stored  both  as  a  street  address  and  geographic 
location  using  latitude  and  longitude  in  degrees,  minutes  and  seconds. 
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culling  the  data  required.  However,  if  the  desired  states  were  not  co-located  in  the  region, 
the  user  would  be  required  to  make  two  separate  queries  and  combine  the  results  or 
retrieve  all  nodes  within  the  national  region,  and  again,  manually  compile  the  results. 

4.  DAMAGE  ASSESSMENT 

This  menu  selection  allows  the  user  to  input  observed  damage  information 
from  natural  or  man-made  sources,  to  execute  simulations  from  an  internal  probabilistic 
model,  and  to  monitor  existing  damage  or  review  journaled  damage. 

Presently  the  damage  assessment  module  is  the  only  Decision  Support  System 
(DSS)  component  present  in  TEDSS  to  support  the  Emergency  Management  Team  (EMT) 
in  extending  the  data  analysis  capabilities.  The  model  determines  what  facilities  were 
most  likely  affected  by  a  nuclear  detonation.  The  model  accepts  information  about  the 
latitude  and  longitude,  blast  height,  direction  and  other  information  about  the  detonation 
to  define  a  rectangular  or  circular  estimate  of  the  affected  areas.  If  the  model  is  executed, 
a  list  of  assets  that  may  have  been  damaged  is  displayed.  The  user  may  then  choose  to 
journal  those  sites  which  may  have  been  affected  for  further  investigation.  These  sites 
may  then  be  recalled  as  required  under  the  List  Journaled  Damage  menu  item. 

5.  TELECOMMUNICATIONS  REQUESTS 

This  menu  item  allows  the  user  to  enter  and  display  claims  for 
telecommunications  services  and  facilities  requests. 

Service  requests  are  created  when  an  agency  wishes  service  restored,  or  initiated 
in  an  emergency  situation.  Facility  requests  are  generated  when  nodes  and/or 
operating  centers  no  longer  provide  vital  communications.  (Short  and  Bockenek, 
1989,  p.  55) 
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All  requests  are  reviewed  by  the  EMT  at  the  National/Regional  Command  Center 
(NCC/RCC).  Then  in  accordance  with  the  current  Emergency  State  of  the  Nation  and  the 
relative  importance  of  the  agency  making  the  claim,  a  priority  for  service  restoration  is 
assigned.  After  receiving  a  priority  the  request  is  forwarded  to  a  service  provider  to 
effect  the  reconnection  of  services.  As  the  emergency  evolves,  the  telecommunications 
service  priority  (TSP)  may  change,  which  in  turn  may  cause  the  service  restoration  order 
to  change.  This  module  also  supports  journaling  of  service  requests,  and  allows  for 
journal  updates  as  requests  are  completed  and  services  restored. 

6.  COMMUNICATIONS 

This  menu  item  facilitates  a  communication  link  between  TEDSS  users.  The 
user  enters  a  message  to  be  mailed  electronically  to  another  user  and  initiates  manually 
the  dialing  of  the  user’s  telephone  number.  It  does  not  apparently  interface  in  any  way 
with  the  TEDSS  database. 

The  current  capabilities  of  TEDSS  meet  the  basic  needs  of  the  EMT. 
However  they  provide  little  assistance  in  guiding,  or  assisting  them  in  the  decision  making 
process.  *  Mitionally  the  menu  structure  does  not  allow  much,  if  any,  flexibility  in  data 
retrieval  and  presentation  methods.  The  following  chapter  will  review  the  emergency  and 
tactical  decision  making  environment  and  provide  a  different  model  of  TEDSS  to 
overcome  some  of  the  present  deficiencies. 
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in.  EMERGENCY  AND  TACTICAL  DECISION  MAKING 


The  computer  can  assist  human  analysis  of  large  quantities  of  data  by  translating 
data  into  more  useful  and  manageable  information.  This  chapter  addresses  the  basic 
concepts  of  decision  support  and  proposes  a  different  concept  of  TEDSS  as  a  Tactical 
Decision  Aid  (TDA)  to  support  the  Emergency  Management  Team  (EMT). 

In  making  the  relevant  information  available  to  operating  public  service  personnel 
in  a  timely,  interactive  mode,  the  system  will  likely  increase  the  power  of  decision 
makers  to  make  appropriate  decisions.  (Comfort,  1985,  p.  41) 

Decisions  based  on  information  provided  by  TEDSS,  or  any  system  being  utilized 
for  emergency  management,  are  greatly  hindered  by  the  lack  of  rules  about  how  the 
system  will  be  utilized.  Decision  ^.okcts  in  emergency  management  "operate  under  the 
recurring  problems  r<>Uocd  by  infonnation  overload,"  and  where  "environmental  conditions 
are  rjq)idly  changing  and  dynamic"  (Comfort,  1985,  p.  41). 

When  dispatched  to  an  emergency  situation,  the  National  or  Regional  Emergency 
Management  Team  (NEMT  or  REMT),  the  National  Communications  Center  (NCC)  and 
the  Federal  Emergency  Communications  Center  (FECC)  personnel  will  be  called  upon  to 
make  resource  decisions  that  could  significantly  affect  resource  allocation  and  the  length 
of  time  until  service  is  restored.  While  organized  and  structured  service  priority  ranking 
systems  such  as  the  Telecommunications  Service  Priority  (TSP)  and  Restoration  Priority 
(RP)  systems  add  structure  to  the  chaos,  unforeseen  contingency  situations  will  require 
local  judgment  as  to  the  most  efficient  procedure  for  restoring  service.  (Booz,  Allen  and 
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Hamilton  Technology  Assessment  Report  I,  1990,  p.  1)  (Booz,  Allen  and  Hamilton 
Integration  Plan,  1989,  p.  7) 

TEDSS  current  text-based  approach  to  the  entry,  retrieval,  and  support  of  decision 
making  are  not  conducive  to  making  effective  decisions.  We  believe  that  providing  the 
EMT  with  the  ability  to  obtain  a  more  visual  presentation  of  information  and  the  ability 
to  dynamically  define  the  display  of  information  will  improve  the  users  decision  quality 
and  speed.  The  tactical  decision  aid  (TDA)  will  provide  this  support. 

A  TDA  will  assist  the  EMT  in  collecting,  correlating  and  applying  available  data 
to  improve  decision  speed  and  quality.  A  TDA  will  providing  him  with  tools  to  assist 
in  modeling  data  to  provide  information  in  the  form  that  they  desire,  not  a  defined  menu 
format. 

A.  DECISION  SUPPORT  SYSTEMS  (DSS) 

Decision  support  systems  focus  on  supporting  the  decision  making  process  rather 
than  a  system  of  information  and  reports.  DSS  "consist  of  three  primary  subsystems  -  a 
data  base,  a  model  base  and  the  decision  maker."  (Sprague  and  Watson,  1983,  p.  21).  Of 
major  importance  is  the  effective  management  of  the  subsystems  and  the  user  interface. 

DSS  are  not  ’intelligent’  in  human  terms,  but  rather  are  programmed  to  be  smart 
assistants  which  present  information  in  a  useful  form  to  support  the  decision  making 
process.  The  computer’s  assistance  is  most  useful  when  handling  a  semi-structured  task 
that  has  accepted  methods  of  handling  information,  but  whose  methods  may  be  eithe"  too 
tim  intensive  or  data  intensive  to  be  handled  manually.  Semi-structured  tasks  involve 
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data  and  the  users’  intuition  and  judgment.  DSS  that  support  credit  application  approvals, 
inventory  management  and  job  scheduling  are  examples  of  tasks  that  have  definable 
criteria.  While  the  computer  can  determine  results  more  efficiently  than  a  human,  it  may 
require  human  judgment  to  compensate  for  variables  that  were  not  taken  into  account  in 
the  model. 

A  DSS  will  identify  relevant  data  attributes,  choose  an  appropriate  model  to 
analyze,  summarize,  and  present  the  information  to  the  user  using  predefined  knowledge 
rules.  The  user  may  accept  or  discard  the  DSS  analysis  and  results  in  his  final  decision 
because  of  factors  that  are  not  available  to  the  DSS.  For  example,  a  loan  officer  may 
approve  a  loan  despite  a  DSS  recommendation  to  the  contrary  because  he  knows  of 
extenuating  factors  not  included  in  the  model  of  loan  approvals. 

The  term  DSS  has  been  used  to  describe  a  broad  range  of  computer  systems,  from 
simple  personal  computer  spreadsheets  to  complex  financial  planning  tools.  For  the 
purposes  of  this  paper,  a  DSS  will  be  defined  as: 

Interactive  computer-based  decision  support  systems  are  sets  of  data  bases, 
models,  and  algorithms  capable  of  solving  operational,  tactical,  and  strategic 
problems.  (Andriole,  1989,  pp.  226-227) 

Of  primary  importance  to  DSS,  regardless  of  any  definition,  is  effective  dialogue 
management  between  the  system  and  the  decision  maker.  It  is  through  an  effective 
interface  with  the  decision  maker  and  integration  of  internal  DSS  subsystems  that  a  DSS 
will  become  a  useful  tool  for  problem  resolution.  (Sprague  and  Watson,  1983,  p.  21 )  The 
following  sub-sections  will  describe  the  key  subsystems  in  a  DSS. 
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1.  Model  Management 

A  model  transforms  data  into  information.  A  model  is  a  careful  description 
of  a  real  system.  Model  Management  is  the  method  of  selecting  the  most  appropriate 
model  of  analyzing  the  data  for  presentation  to  the  user.  A  model  may  range  from  a 
simple  tabular  summary  to  a  complex  statistical  profile,  and  will  normally  provide  a 
condensed  t^praisal  of  the  relevant  information.  A  model  is  not  constrained  to 
mathematical  relations  between  data  fields;  it  may  also  consist  of  knowledge  in  the  form 
of  rules  which  form  a  model  of  one  or  more  person’s  expertise. 

2.  Data 

Data  are  the  raw  materials  which  drive  the  execution  of  models  and 
knowledge  bases.  DSS  often  rely  upon  external  databases  to  provide  the  storage, 
retrieval,  and  administration  of  data. 

3.  Knowledge  Base 

A  knowledge  base  is  a  collection  of  facts  stored  as  logic  rules,  heuristics,  or 
algorithms  which  provide  the  DSS  with  "intelligence."  Heuristics  or  "rules  of  thumb"  are 
broad  generalizations  which  have  been  determined  to  be  accurate  in  shilling  the 
presentation  of  information  for  decision  making.  A  knowledge  rule  for  credit  approval 
might  be  "no  credit  will  be  approved  if  the  applicant  has  declared  bankruptcy,"  or  "all 
credit  cards  must  have  less  than  ten  percent  of  the  credit  limit  used." 
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4.  Dialogue  Management  or  User  Interface  (UI) 

Dialogue  Management  or  User  Interface  (UI)  is  the  glue  which  holds  the  DSS 
components  together;  it  is  the  porthole  to  the  system.  "From  the  users’  viewpoint  the 
interface  is  the  system  and  the  main  issue  in  design  is  how  the  system  should  appear  to 
the  user."  (Keen,  1983,  p.  171). 

The  DSS  must  mimic  or  support  the  user’s  efficient  decision  making  process 
to  be  effective.  Information  or  queries  may  be  p’^esented  graphically,  question  and  answer 
dialogue,  or  other  methods  maybe  used.  However,  the  system  UI  must  be  consistent  with 
the  users’  own  method  of  problem  solving.  If  the  system  violates  that  dictum,  the  user 
will  become  frustrated  and  confused,  have  more  difficulty  in  using  the  system  effectively, 
and  ultimately  will  lose  motivation  to  use  the  system.  (Wagner,  1989,  p.  A-1) 

B.  EXISTING  DSS  SUPPORT  FOR  TEDSS 

Presently  the  TEDSS  has  no  internal  DSS  capabilities  beyond  the  damage 
assessment  model  discussed  in  Chapter  II.  The  Expert  Telecommunications  Resource 
Allocation  Module  (XTRAM)  was  a  knowledge  base  developed  to  support  the  Resource 
Allocation  Officer  and  Emergency  Management  Team  (EMT)  in  prioritizing  and 
managing  resource  allocation  when  using  TEDSS.  A  prototype  of  XTRAM  was 
developed  on  a  different  hardware  platform,  and  it  has  not  been  determined  when,  or  if, 
the  conversion  to  the  deployable  version  of  TEDSS  will  be  made.  (Booz,  AUen  and 
Hamilton  Deployment  Plan,  1988,  p.  15),  (Booz,  Allen  and  Hamilton  Integration  Plan, 
1989,  p.  5) 


19 


Regardless  of  the  future  of  XTRAM,  it  did  demonstrate  that  TEDSS  can  utilize  DSS 
capabilities.  TEDSS  should  translate  incoming  data  into  information  which  the  user  can 
process  to  make  the  best  possible  decision  at  the  time.  It  should  also  alert  the  EMT  as 
the  implications  of  previous  decisions  emerge  and  the  situation  changes. 

C.  TACTICAL  DECISION  AIDS  (TDA) 

A  TDA  can  be  considered  as  a  special  type  of  DSS  which  is  organized  to  assimilate 
rapidly  changing  information  to  support  the  best  possible  decision  in  a  limited  time  frame. 
Decisions  are  intended  to  ’satisfice’  rather  than  optimize  in  this  kind  of  environment. 

TDAs  differ  from  conventional  DSSs  in  their  utilization  of  dynamic  situational 
information  to  support  decisions  that  help  secure  a  strategic  objective.  Tactical  systems 
normally  receive  continuous  streams  of  information  from  sensors;  or  other  information 
systems  to  support  their  analysis  models.  The  streams  of  data  processed  through  TDA 
models  provide  real-time  or  near-real-time  information  to  a  tactical  decision  maker  who 
continuously  reacts  to  the  implications  of  the  changing  data. 

Tactical  DSSs  are  becoming  more  critical  on  the  electronic  battlefield  as  they 
provide  operational  units  with  the  tools  to  process  large  amounts  of  incoming  electronic 
data  for  real  time  battle  management.  The  data  may  come  in  the  form  of  pre-formatted 
messages,  motion  sensors,  satellite  downlinks,  or  numerous  other  electronic  forms. 
Although  TDAs  are  often  associated  with  the  military,  they  are  useful  for  any 
organization  requiring  real-time  or  near  real-time  support  for  decisions. 
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TEDSS  assists  emergency  management  teams  decisions  in  a  real-time  environment. 
However,  unlike  a  military  combat  information  center  (CIC),  decisions  regarding 
incoming  threats  are  normally  required  in  tens  of  minutes  versus  minutes  or  seconds. 
This  difference  does  not  alter  TEDSS  requirements  for  real  time  information,  but  it  does 
allow  TEDSS  more  flexibility  to  evaluate  multiple  scenarios,  and  therefore,  provide  more 
effective  resource  allocation. 

Although  TEDSS  decisions  are  not  as  time  critical  as  some  military  applications. 
If  made  incorrectly,  they  could  nevertheless  result  in  significantly  increased  amoimts  of 
service  time  lost,  and  materially  affect  the  nation’s  communications  assets.  The 
TEDSS/TDA  concept  would  allow  the  "evaluation  of  alternative  plans  or  concepts  of 
operation,”  and  could  warn  the  Emergency  Management  Team  (EMT)  of  possible  rule 
violations  and  encourage  multiple  ways  of  looking  at  solutions  to  the  problem.  (Andriole 
and  others,  1991,  p.  170).  The  extension  of  TEDSS  to  support  the  EMT  in  projecting  the 
effect  of  the  current  decision  will  assist  in  making  decisions.  If  future  information 
indicates  that  the  original  assumptions  made  by  the  EMT  were  based  on  faulty 
information,  the  ’story’  or  directions  may  be  adjusted. 

D.  TEDSS  DECISION  ENVIRONMENT 

The  TEDSS  emergency  management  environment  can  be  viewed  as  primarily  a 
Command  and  Control  (C^)  system  dedicated  to  controlling  and  directing  all  available 
communication  assets  and  to  restoring  telecommunications  assets  and  communications 
links  in  order  of  greater  national  importance.  The  decisions  required  for  restoring  those 
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communications  wUl  rarely  follow  a  simple  path.  TEDSS  should  support  those  changes.- 
Tactical  decisions  concerning  resource  management  can  be  supported  by  a  Tactical 
Decision  Aid  (TDA).  The  ability  to  model  the  results  of  related  decisions  over  a  period 
of  time,  or  storyboard  can  be  a  powerful  tool  in  decision  support.  (Andriole,  1985, 
p.  170) 

Designing  an  effective  DSS  or  TDA  for  managing  under  emergency  conditions  is 
a  significant  challenge  because  of  the  ill-defined  problems  that  must  be  addressed. 
Situations  are  likely  to  be  changing  rapidly,  and  data  which  is  received  from  multiple 
imtrained  or  unreliable  sources  must  be  evaluated  on  the  basis  of  its  accuracy  and 
relevance.  Additionally,  critical  decisions  may  be  required  within  this  dynamic 
environment  that  may  have  no  correct  answer.  The  EMT  may  be  required  to  decide 
between  restoring  communication  at  several  nearby  sites  or  a  distant  site  in  which  all  have 
equal  restoration  priority.  Suppose  the  closest  sites  will  take  longer  to  restore  than  the 
distant  ones.  In  this  scenario,  which  site  will  offer  the  most  benefit? 

In  addition  to  the  marked  increase  in  the  complexity  and  rate  of  demands  made 
upon  the  information  processing  capacity  of  the  decision-makers  under  emergency 
conditions,  the  ability  of  human  decision-makers  to  manage  complexity  tends  to 
decrease  under  stress.  (Comfort,  1985,  p.  41) 

These  counterproductive  conditions  of  increased  information  processing 
requirements  and  reduced  ability  for  processing  may  be  partially  controlled  by  training 
and  simulations.  TEDSS  must  provide  a  knowledge  base  of  information  and  some  form 
of  interactive  information  manager  to  support  the  user  in  managing  incoming  data  and  to 
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"extend  the  capacity  of  human  decision-makers  operating  imder  conditions  of  complexity 
and  stress."  (Comfort,  1985,  p.  41). 

The  interactive  information  manager  should  be  conAgured  ideally  to  complement 
the  decision  making  process,  leading  the  user  through  a  series  of  steps  to  determine  the 
optimal  answer.  This  is  not  usually  possible!  In  addition,  the  system  should  provide  a 
consistent  interface  in  keeping  with  the  user’s  conceptual  model  of  how  the  information 
will  be  utilized.  The  user’s  conceptual  model  is  the  knowledge  base  the  user  has 
developed  to  rationalize  the  behavior  of  a  system.  Violating  the  user’s  model  may  lead 
to  confusion,  long  learning  times,  and  more  critically,  poor  retention  of  the  process  as 
well  as  undermining  his  motivation  to  use  the  system.  TDAs  allow  a  more  unstructured 
"what-if  simulation  and  create  a  simulation  of  probable  events  resulting  from  each 
foUow-on  decision.  For  example,  TDAs  using  a  simulation  model  can  show  the  effects 
of  six  hours  of  repair  work  within  a  few  minutes.  This  provides  the  EMT  with  a 
’snapshot’  of  an  anticipated  future  situation,  the  desirability  of  which  can  then  be 
evaluated. 

E.  STORYBOARDING  AS  A  TOOL  FOR  SOLVING  PROBLEMS 

It  has  been  recognized  that  a  failure  to  determine  adequately  the  requirements  of  an 
information  system  (IS)  can  often  lead  to  the  automation  of  the  wrong  things.  Systems 
that  are  implemented  with  insufficient  user  input  have  led  to  systems  that  are  not  used. 
One  study  found  that: 
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20-40%  of  all  system  problems  can  be  traced  to  problems  in  system  development 
process,  while  60-80%  can  be  traced  to  inaccurate  requirements  definitions.  The 
message  is  clear:  know  thy  user.  (Andriole,  1991,  p.  82) 

Systems  that  meet  either  the  user’s  or  task  requirements  may  fail  to  meet  the  larger 

organization  goals  or  mission  and  hence  may  not  support  the  ultimate  organization 

mission.  The  best  requirements  analysis  would  be  to  form  a  "matrix  linking  all  three 

dimensions  (user,  task,  and  organizational/doctrinal)  together."  (Andriole,  1987,  p.  82). 

Requirements  are  often  not  incoiporated  into  the  eventual  system.  Several  studies 
trying  to  understand  why  this  occurs  could  reach  no  conclusive  findings.  However  it  can 
be  said  that: 

The  systems  design  and  developmental  process  carmot  be  successfully 
implemented  unless  requirements  are  identified  and  refined  via  some  verifiable 
methodology.  (Andriole,  1987,  p.  83) 

After  countless  systems  were  thrown  out  due  largely  to  their  incompatibility  with 
established  efficient  problem-solving  procedures,  designers  began  to  take  note  of 
the  environment  in  which  their  systems  were  expected  to  perform.  (Andriole,  1987, 
p.  85) 


One  proposed  solution  to  overcome  the  translation  of  a  conceptual  system  to  an 
operational  system  has  been  the  prototyping  methodology.  A  prototype  is  the  shell  of  the 
final  proposed  system,  validated  by  the  user.  The  prototype  provides  most  of  the 
graphical  or  input/output  functions  to  ensure  the  system  designer  has  adequately 
understood  the  requirements.  The  review  of  the  prototype  will  also  address  whether  the 
user  adequately  described,  or  conceptualized,  the  system  during  requirements  analysis. 
By  validating  the  requirements  early  in  the  design  process,  revision  or  correction  of  the 
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requirements  may  be  accomplished  with  less  costs  and  problems  than  by  waiting  for  the 
finished  product. 

A  specific  form  of  prototyping  is  storyboarding.  Storyboards  are  an  interactive 
attempt  to  capture  the  screen  and  systems  interactions  during  the  design  process. 
Storyboards  are  created  by  the  designer  and  validated  by  the  user.  Each  input/output 
screen  or  ’page’  is  connected  in  a  series  of  screens  for  the  user  to  traverse.  The  user’s 
traversal  of  the  screens  simulates  actions  which  would  be  done  on  the  finished  system 
without  real  data.  The  results  of  the  ’story’  should  be  a  set  of  screens  that  the  designer 
will  program  to  meet  the  user’s  needs  and  expectations. 

The  storyboard  concept  is  not  constrained  to  the  design  process.  The  EMT  could 
record  or  trace  his  steps  in  solving  a  problem,  or  simulate  a  situation  to  detennine  the 
outcome  of  decisions.  If  the  results  are  not  as  desired,  the  story  may  be  'retold’  mnning 
through  different  steps  until  a  best  or  satisfactory  ending  is  found  for  the  scenario  being 
considered. 

F.  REVISED  SCHEMA  FOR  TEDSS  AS  A  TDA 

The  present  TEDSS  may  be  simplistically  considered  an  enhanced  database  package 
with  preprogrammed  queries.  The  spatial  relationship  of  communication  assets  are  stored 
within  TEDSS,  but  the  utilization  of  these  relationships  in  solving  problems  is  not 
transferred  to  the  user.  TEDSS  requires  textual  input  and  provides  textual  or  graphical 
(Mapinfo)  output  to  questions  regarding  asset  availability.  The  user  must  make  a  mental 
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model  of  the  geographic  area  and  transfer  the  text  information  entered  into  or  received 
from  TEDSS  to  his  spatial  model  to  solve  problems. 


TTie  more  information  you  can  absorb  visually,  the  quicker  you  can  come  to  a 
decision.  Everyone  can  read  a  map.  It  doesn’t  look  abstract,  and  it’s  much  more 
appealing  that  looking  at  tables  of  figures.  (Bylinsky,  1989) 

The  proposed  revised  TEDSS,  shown  in  Figure  3,  proposes  moving  from  a  primarily 

text  based  input/output  to  a  graphical  one.  Communication  whenever  possible  will  be 

done  through  pointing,  or  selecting  from  a  number  of  options  and  entry  from  a  keyboard. 

The  user  will  determine  which  method  is  most  suited  to  his  needs. 


Figure  3  Proposed  TEDSS  II  block  diagram 
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The  proposed  system,  called  TEDSS  n  for  clarity,  will  utilize  a  graphical  user 
interface  (GUI)  windowing  environment.  The  GUI  is  the  ’glue’  for  the  system;  it  must 
suppoit  multiple  windows  to  allow  mental  comparisons  between  different  scenarios. 

TEDSS  n  will  also  utilize  a  graphical  metqjhor  for  the  presentation  of  information 
on  locations.  A  geographic  information  system  (GIS)  will  be  used  as  the  primary  method 
for  displaying  and  inputting  information  related  to  a  specific  location.  By  pointing,  the 
users  will  define  the  area  of  interest  on  a  m£q>,  then  navigate  through  menus  and  dialogue 
boxes  to  query  data,  with  the  results  displayed  on  the  map.  By  the  use  of  a  gr^hical 
user  interface  and  a  windowing  system,  the  user  may  have  information  on  the  area  in 
several  different  forms  located  in  different  windows.  For  example,  the  EMT  may  have 
the  GIS  showing  a  map  of  the  affected  area  in  one  window,  a  separate  window  with  the 
results  of  an  structured  query  language  (SQL)  query  listing  all  nodes  in  a  particular 
network  in  the  region,  and  a  third  window  with  a  draft  message  listing  the  priority  of 
service  restoration  as  generated  by  XTRAM  operating  in  fourth  window. 

TEDSS  n  will  attempt  to  minimize  requirements  for  the  user  to  switch  between 
input  devices  by  presenting  a  number  of  menu  selections  in  a  dialogue  box.  The  user 
may  select  from  a  presented  list  or  enter  an  alternate  answer.  Query  results  will  normally 
be  mapped  onto  an  existing  display  map  or  can  be  presented  in  a  separate  window.  The 
primary  method  of  navigation  will  be  the  menus  and  dialogue  boxes.  However  a  direct 
SQL  link  to  the  database  can  be  provided  to  allow  the  user  to  create  a  query  manually 
when  desired.  The  SQL  query  interface  will  allow  knowledgeable  users  to  quickly  cieate 
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complex  queries  when  the  menu  selections  do  not  immediately  support  the  information 
presentation  required. 

TEDSS  n  use  of  windows  and  a  ’point  and  shoot’  selection  process  of  navigating 
through  menus  and  dialogues  boxes  should  facilitate  the  learning  of  TEDSS,  provide  tools 
for  the  EMT  to  configure  and  maximize  use  of  the  system,  and  remove  the  artificial 
barriers  to  effective  decision  making  present  in  the  current  system. 
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rv.  COMPONENTS  OF  PROPOSED  SYSTEM 


TEDSS  n  as  outlined  in  the  previous  ch^ter  will  be  oriented  heavily  toward  a 
graphical  implementation  allowing  the  user  to  select  and  handle  information  primarily  in 
a  graphical  rather  than  textual  form.  Options  for  the  user  who  needs  or  desires  direct 
control  of  the  data  will  also  be  available.  The  system  should  not  define  how  things 
should  be  done,  but  rather  support  what  the  emergency  management  team  (EMT)  needs 
to  accomplish  his  mission. 

TEDSS  n  will  consist  of  three  core  sections:  the  graphical  user  interface  (GUI), 
the  geographic  information  system  (GIS)  and  a  database  storage  mechanism.  The 
remaining  components  or  modules  in  the  proposed  system  and  other  applications  to  be 
developed  will  serve  to  enhance  system  capabilities.  They  may  be  added  incrementally 
as  the  technology  and  users’  expectations  advance.  The  user  will  interface  with  each 
component  through  the  GUI. 

The  model  base  will  contain  the  damage  assessment  model  and  other  tools  for 
shaping  the  data  to  assist  in  decision  making.  Additional  models  to  facilitate  hurricane 
tracking  or  assessing  earthquake  damage  may  be  added  if  useful  to  the  National 
Communications  System  (NCS).  All  models  would  access  data  from  the  database  and  use 
the  GUI  or  GIS  to  present  the  results  of  the  model.  While  additional  models  will  be 
helpful  in  extending  the  power  of  TEDSS,  the  models  may  require  modifications  to  insure 
conformance  with  the  established  common  GUI.  Failure  to  insure  that  the  integrity  and 
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conformance  to  the  interface  is  maintained  in  all  components  will  be  detrimental  to  the 
TEDSS  n  usability. 

A  voice  recognition  interface  will  provide  an  alternate  method  of  menu  navigation 
and  may  be  useful  in  command  center  operations  and  briefings.  The  following  sub¬ 
sections  address  these  system  components  in  greater  detail. 


A.  GRAPHICAL  USER  INTERFACE  (GUI) 

The  graphical  interface  or  GUI  can  be  considered  the  ’glue’  which  holds  the  system 
together  and  makes  all  the  parts  appear  as  an  integral  unit:  "’a  single  system  image’ 
concept  where  the  complexities  of  the  environment  are  hidden  behind  a  user-oriented 
interface."  (Nicholls,  1990,  p.  164).  The  GUI  concept  is  based  on  supplying  a  uniform 
way  of  presenting  menu  selections  and  information  to  the  user. 

To  achieve  these  goals,  the  GUI  imposes  a  set  of  restrictions  on  the  methods  for 
program  and  user  interaction,  with  a  suggested  set  of  standards  based  on  experience 
and  UI  research.  Not  only  is  this  usually  better  designed  than  the  ad  hoc  U1  of 
current  t^lications,  it  is  consistent  across  the  {q^plication  spectrum.  Learning  a 
new  application  imder  a  GUI  benefits  from  the  transference  of  previous  learning 
because  of  UI  consistency.  (Nicholls,  1990,  p.  164) 

The  GUI’s  adherence  to  a  set  of  standards  in  TEDSS  n  £q>plications  will  greatly 

enhance  training  by  requiring  the  user  to  learn  new  capabilities  rather  than  new 

procedures.  The  ability  to  add  new  functional  components  or  models  to  TEDSS  n  while 

using  a  common  interface  will  allow  the  EMT  to  r£q)idly  assimilate  new  capabilities  or 

update  existing  systems  with  little  or  no  additional  training. 

Because  such  crises  are  so  infi-equent,  the  training  mode  [for  emergency 
management]  becomes  even  more  essential  than  for  business  decisions.  (Seagle, 
Duchessi  and  Belardo,  1985,  p.  66) 
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Once  the  user  is  introduced  to  a  GUI  and  understands  its  basic  interface  structure, 


the  learung  of  TEDSS  can  be  focused  primarily  on  the  problem  of  re-establishing 
communications. 

1.  Advantages  of  a  GUI 

The  primary  advantages  of  a  GUI  is  that  the  user  needs  only  master  a  single 
standard  method  of  interfacing  with  applications.  Each  computer  application  is  required 
to  conform  to  a  standard  interface  which  insiures  that  users  work  with  the  same  interface 
regardless  of  the  application.  This  simplifies  the  familiarization  process  and  reduces 
training  time.  While  standards  are  an  important  advantage  to  a  GUI  for  emergency 
management,  a  GUI’s  ability  to  provide  graphical  representations  and  communicate 
visually  instead  of  textually  may  be  more  important  to  the  EMT. 

The  old  adage  of  ’a  picture  is  worth  a  thousand  words’  is  true  for  users. 
Computer  users  at  all  skill  levels  master  computer  tasks  more  rapidly  when  done  in  a 
graphical  environment.  The  EMT,  using  a  GUI  in  concert  with  a  visual  map  model 
(GIS),  where  not  only  location  information  is  presented  consistently  with  their  mental 
model  but  colors  and  icons  are  used  effectively,  may  be  able  to  assimilate  significantiy 
more  information  than  with  the  current  TEDSS.  A  GUI’s  ability  to  expand  or  contract 
views  and  present  data  in  several  forms  and  scales  should  allow  TEDSS  n  to  present 
infonnation  in  a  way  that  is  more  meaningful  to  the  EMT.  TEDSS  II  makes  a  conceptual 
shift  from  requiring  the  user  to  understand  the  system  in  order  to  accomplish  his  job  to 
making  the  system  support  the  user  and  his  needs. 


31 


2.  GUI  Flavors 


There  are  presently  four  commercially  successful  GUIs  in  wide  use  today; 
Microsoft  (MS)  Windows,  Apple  Macintosh  (MAC),  Presentation  Manager  (PM),  and 
X-Windows.  Each  GUI  is  wedded  to  a  specific  operating  system  and  in  many  respects 
cannot  be  considered  separately  from  the  operating  system.  However,  developers  have 
been  trying  to  convert  applications  written  for  one  GUI  to  other  GUIs.  For  example,  MS 
Windows  applications  may  be  used  in  OS/2,  version  2.0,  and  UNIX  workstations  with 
additional  specialized  hardware  may  operate  Macintosh  software  concurrently  with  X- 
Windows. 

All  of  the  above  GUIs  use  a  windowing  metaphor  that  allows  users  to  resize, 
move,  hide  or  overlap  windows  as  desired.  Additionally  most  support  the  ability  to 
minimize  a  window  into  an  icon  to  clean  up  the  screen  or  ’desktop.’  All  GUIs,  except 
MS  Windows,  require  the  user  to  utilize  a  mouse  or  pointing  device.  The  ability  to 
effectively  integrate  a  pointing  device  is  required  for  an  efficient  work  environment. 
While  each  GUI  performs  the  same  basic  function,  users  may  disagree  as  to  the  ability 
and  ’user  friendliness’  of  each  implementation.  The  following  sections  provide  a  quick 
overview  of  the  salient  features  of  the  four  GUI  environments.  Chapter  V  addresses  the 
operating  system  issues  associated  with  GUIs. 

a.  Microsoft  Windows  (WIN3) 

MS  Windows  (WIN3),  was  released  commercially  in  1987.  With  the 
release  of  version  3.0  in  1990,  it  has  become  a  dominant  force  in  the  commercial  softv.-are 
market.  WIN3  operates  as  a  graphical  shell  to  DOS,  creating  either  a  pre-emptive  or 
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cooperative  multi-tasking  environment  depending  on  the  WINS  mode  utilized.  WINS 
does  not  require  a  pointing  device,  but  is  significantly  more  difficult  to  use  without  one. 
The  use  of  resizable  windows  and  icons  guides  the  user  through  most  tasks.  WINS 
supports  the  ability  of  users  to  cut  text  or  graphics  from  one  document  window  and  paste 
it  into  another  document.  However  some  tasks  such  as  managing  ^plications  and  adding 
programs  are  not  intuitively  obvious.  Microsoft  adopted  IBM’s  Common  User  Access 
(CUA)  standards  to  specify  the  basic  menu  structure  of  applications  and  what  actions 
specific  keys  should  perform.  However,  the  standards  are  not  always  followed  by 
application  developers,  especially  in  early  WIN  applications. 

While  WIN3  greatly  simplifies  many  computer  tasks,  it  is  not  always  a 
stable  platform.  WIN3  itself  may  abort  for  unknown  reasons,  caUed  unrecoverable 
application  errors  (UAE),  because  of  incompatibility  of  WIN3  and  the  hardware,  or  more 
often  by  a  violation  of  a  process  running  in  one  of  the  windows. 

Because  DOS  does  not  support  multi-tasking,  it  cannot  provide  WIN3 
with  support  should  two  applications  try  and  use  the  same  resources.  Therefore,  WIN3 
must  create  the  multi-tasking  environment  while  operating  as  a  single  application  in  DOS. 
WIN3’s  multi-tasking  environment  is  very  powerful,  but  is  susceptible  to  unexpected 
terminations  when  an  application  operating  in  WIN3  fails  or  acts  improperly  on  system 
resources.  The  result  of  these  types  of  problems  may  require  the  computer  to  be  restarted 
resulting  in  a  loss  of  all  unsaved  work.  Microsoft  has  stated  it  intends  to  eventually 
replace/remove  DOS  and  allow  WIN3  to  take  over  the  operating  system  responsibilities 
in  future  versions  which  should  significantly  improve  WTN3’s  stability.  Initially 


33 


Microsoft  planned  to  merge  the  OS/2  operating  system  and  Windows  GUI  platforms; 
however  they  have  recently  modified  their  development  plans  concerning  WIN3,  so  this 
direction  may  change  again.  (Sherer,  1991,  p.  1) 

b.  Apple  Macintosh  (MAC) 

The  Apple  Macintosh  (MAC),  released  initially  in  1984,  may  be  the 
oldest  commercial  GUI.  It  was  derived  from  research  by  Xerox  Corporation  and  all  GUI 
tend  to  be  judged  as  to  how  well  they  "look  like  a  MAC."  The  MAC  interface  is  refined, 
intuitive  and  consistent  across  aU  applications.  The  MAC’S  GUI  is  intimately  and 
inseparably  tied  to  the  operating  system.  Unlike  DOS,  the  MAC  provides  standard 
methods  for  controlling  all  input  and  output  operations.  The  MAC  supports  cutting  and 
pasting  between  documents,  and  dynamically  linking  programs.  For  example,  a  chart  may 
be  linked  to  a  spreadsheet  so  that  when  numbers  in  the  spreadsheet  are  changed  the  gr^h 
is  adjusted. 

c.  Presentation  Manager  (PM) 

Presentation  Manager  (PM)  released  initially  in  1988,  was  developed  for 
International  Business  Machines  (IBM)  Operating  System/2  (OS/2),  which  was  released 
in  1987  by  Microsoft  Corporation.  While  PM  was  not  critical  to  the  original  function  of 
OS/2,  it  is  now  the  primary  interface  for  the  operating  system  and  will  be  considered 
synonymous  with  PM  for  the  remainder  of  the  thesis.  PM  does  not  use  as  many  graphical 
meti^hors  as  WIN3  or  MAC,  but  does  support  the  same  basic  features  for  configuring 
the  desktop  and  for  inter-application  data  transfer. 
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OS/2,  like  the  Macintosh,  has  an  advantage  in  that  it  is  a  new  operating 
system,  and  is  not  consti'ained  to  support  applications  developed  for  previous  systems,  as 
was  the  case  for  MS  Windows  and  DOS.  OS/2  uses  the  CUA  to  specify  in  detail  how 
applications  should  create  their  menu  structure  and  keystroke  definitions.  Additionally 
because  OS/2  and  PM  were  designed  from  die  start  as  a  multi-tasking,  multi-threaded 
operating  system,  OS/2  has  a  robust  ability  to  handle  application  failures  without 
impacting  other  applications.  This  provides  a  more  stable  and  reliable  environment  than 
WIN3,  by  not  allowing  one  process  to  disable  the  whole  system. 

d.  X-Windows 

X-Windows,  strictly  speaking  is  not  a  GUI  for  UNIX,  but  a  "network 
transparent  windowing  system."  (Fielder,  1989,  p.  124).  It  provides  a  common  base  for 
UNIX  user  and  application  programs.  Developed  by  Massachusetts  Institute  of 
Technology  (MIT)  in  cooperation  with  industry  representatives,  X-Windows  is  a  hardware 
independent  method  of  displaying  graphical  information.  It  allows  software  developers 
to  develop  programs  that  concentrate  more  on  the  functions  of  an  application  rather  than 
the  mechanics  of  displaying  it.  Utilizing  X-Windows  as  a  standard  baseline.  Open  Look 
(a  GUI  promoted  by  Sun,  AT&T,  and  UNIX  International  [UI])  and  Motif  (promoted  by 
the  Open  Software  Foundation  [OSF])  are  competing  in  the  marketplace  to  define  a 
’standard’  GUI  for  UNIX/workstation  software  market.  Because  X-Windows  based  GUIs 
did  not  define  the  exact  details  of  application  menus  prior  to  some  triplications  being 
released,  the  user  interface  and  menu  structure  are  not  entirely  consistent  across 
applications.  X-Windows  is  designed  to  operate  transparently  on  a  network,  but  will 
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operate  on  stand  alone  machine  as  well.  As  with  the  preceding  GUIs,  X-Windows, 
through  UNIX  inter-process  communications,  supports  data  linking  between  applications. 

3.  Considerations  in  GUI  Selection 

The  GUI  will  affect  TEDSS  II  more  than  any  other  single  component  in  the 
system.  Its  selection  should  be  based  on  what  system  will  best  satisfy  the  present  and 
future  requirements  of  TEDSS.  Issues  such  as  development  tools  and  applications  are 
important,  but  "as  always,  the  requirements  definition  should  determine  the  relationship 
between  structure  and  flexibility;  designer  preference  should  never  determine  it." 
(Andriole,  1989,  p.  105). 

Each  of  the  four  GUIs  discussed  has  certain  advantages  that  the  others  do  not, 
however  each  environment  has  potential  flaws  that  could  seriously  impede  TEDSS  n 
usability,  stability  and  growth  potential.  Because  of  the  intimate  relation  between  the 
GUI  and  the  operating  system,  a  summary  of  their  strengths  and  weakness  will  be 
included  after  discussing  operating  system  issues. 

B.  GEOGRAPmC  INFORMATION  SYSTEM  (GIS) 

A  GIS  is  a  spatial  database  which  manipulates  location  information  in  the  same 
ways  as  a  conventional  database  handles  data.  GISs  allows  information  retrieval  on 
spatial  data  where  the  geographic  location  is  the  ’common  key’  for  the  data. 

A  ’true’  GIS  does  not  store  maps  in  the  conventional  sense;  radier  they  store  a 
mapping  of  locations  on  the  earth’s  surface  as  well  as  any  relationships  between  locations. 
For  example,  a  state  is  stored  as  a  collection  of  points  defined  by  latitudes  and  longitudes, 
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with  a  defined  relationship,  normally  a  line  or  arc,  that  relates  the  points  which  outline 
the  border  of  the  state.  Rivers  and  other  landmarks  are  stored  similarly.  When  the  GIS 
displays  the  stored  information  the  data  is  projected  onto  the  screen  and  by  use  of  color 
codes  and  icons  a  ’map’  is  drawn.  Tlie  map  is  a  graphical  model  that  is  expedient  for 
human  interpretation  of  data,  but  a  GIS  interprets  it  as  a  collection  of  data  points  with 
attributes. 

Most  GIS  store  information  in  overlays,  like  sheets  of  tracing  paper  over  a  map, 
each  overlay  containing  one  specific  type  of  attribute  and  associated  with  specific  point(s). 
For  TEDSS  each  overlay  could  be  a  telecommunications  network  of  concern  to  the  EMT. 
When  the  EMT  is  evaluating  options  with  the  GIS,  only  the  overlays  of  concern  need  be 
projected  onto  the  area  map,  providing  an  intelligent  filtering  of  information  to  the  user. 

GISs  have  traditionally  been  used  by  relatively  few  people  due  to  their  taxing 
hardware  performance  requirements,  however  powerful  workstations  now  make  these 
systems  available  to  an  increasingly  large  numbers  of  users.  Police  departments  use  GISs 
to  identify  crime  trends,  marketing  people  use  demographic  information  to  target  specific 
zip  codes  and  names,  and  city  governments  use  GIS  to  track  electrical,  water  and 
sanitary  systems,  and  to  review  digging  permits. 

1.  Flavors:  Full  vs.  Limited  GIS 

The  breadth  of  capabilities  in  GISs  vary  dramatically.  More  elaborate  GIS 
may  provide  procedures  for  complex  statistical  profiles  of  demographic,  economic,  or 
other  criteria  projected  onto  a  map  to  assist  in  marketing  decisions  and  political 
redistricting.  A  more  elementary  GIS  may  simply  display  a  map  with  major  roads  and 
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cities  and  other  user  defined  attributes.  TEDSS  need  for  GIS  capabilities  will  depend  to 
a  large  extent  on  the  present  and  future  availabUity  of  data  of  a  spatial  nature  for  the  GIS. 

An  example  of  a  more  powerful  GIS  is  Comgrq>hix’s  MapGrq)hix  program 
which  is  representative  of  GISs  supported  on  many  platforms.  Comgrs^hix’s  M^>Gri^hix 
program  for  the  Macintosh  is  representative  of  a  full  GIS  which  provides  a  robust  set  of 
tools  to  support  users  needs  for  GIS  support  in  one  package.  M^>Grq)hix  is  able  to 
handle  maps  maintained  in  fifteen  different  coordinate  systems,  allows  users  to  create  and 
customize  icons  for  placement  on  maps,  supports  file  and  map  overlay  locking  for 
security  control,  operates  across  a  local  area  network,  and  imports/exports  maps  and  data 
to  a  multitude  of  platforms  and  other  application  programs.  The  program  can  manage  or 
access  data  through  a  database  co-located  on  the  machine  or  a  database  server  using  an 
SQL  interface.  Mapgraphix  offers  development  kits  to  allow  users  to  generate  customized 
s^lications  and  to  extend  current  abilities  to  specialized  mapping  functions. 

TerraView  by  TerraLogics  Inc,  is  an  example  of  a  more  limited  system  which 
takes  a  slightly  different  approach  to  GIS  support.  TerraView  operates  on  X- Windows, 
Digital  and  IBM  mini-computers,  and  IBM  PC’s  and  effectively  provide  a  toolkit  for 
plication  developers  to  create  a  GIS  product.  TerraView  has  a  library  of  functions  to 
facilitate  mapping  applications  through  C  programming  language  function  calls. 
Applications  that  are  developed  by  using  function  calls  may  be  easily  ported  to  different 
platforms,  and  remain  independent  of  the  hardware.  TerraView  allows  users  to  provide 
as  many  or  as  few  options  in  a  mapping  program,  and  provides  an  optimized  spatial 
search  and  retrieval  engine  accessing  an  external  database  to  provide  increased  system 
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speed.  The  ability  to  create  tailored  applications  to  provide  optimized  performance  allows 
TerraView  applications  to  run  potentially  quicker  than  a  comparable  full  featured  GIS. 

TEDSS  presently  stores  location  data  about  network  nodes  and  other 
communication  assets.  If  little  additional  data  is  to  be  collected  or  monitored  by  TEDSS, 
and  if  access  to  communication  asset  information  is  not  provided  by  commercial  carriers, 
many  commercially  available  GIS  will  be  more  powerful  than  what  TEDSS  n  needs.  The 
use  of  a  GIS  which  has  more  capabilities  than  required  will  offer  TEDSS  growth 
capability,  but  it  will  also  provide  sub-optimal  performance  at  the  present  time.  An 
option  to  limit  the  performance  penalty  from  using  an  overpowered  GIS  in  TEDSS  is  to 
program  a  custom  GIS  for  TEDSS  such  as  TerraView  supports  that  implements  only  those 
features  required  at  the  present  time,  but  which  allows  upgrading  as  needs  evolve. 

2.  Utilization  of  a  GIS  in  TEDSS 

The  GIS  offers  many  capabilities  to  the  EMT.  Table  1  lists  several  questions 
that  the  EMT  might  pose  j’.ju  i.;'»ssible  information  the  GIS  could  provide  the  user  or 
model. 
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TABLE  1:  EMT  questions  that  a  GIS  could  assist  in  answering 


Emergency  Management  Team 
Questions 

Information  the  GIS  could 
assimilate 

Describe  the  affected  location  in 
different  ways,  and  what  is  the  impact 
of  the  damage? 

The  following  resources  are  in  the  area 
...  These  networks  are  down  and  the 
sites  in  blue  have  no  alternate 
communication  paths. 

Hunting  through  geographic  space  to 
find  where  certain  conditions  are 
satisfied. 

How  many  nodes  are  potentially 
affected  by  the  earthquake  in  this 
region,  within  a  30  mile  radius? 

What  is  the  differences  between  the 
results  across  two  moments  in  time? 

How  many  nodes  have  been  repaired 
in  the  last  hour? 

What  anomalies  are  there  that  do  not  fit 
the  normal  pattern  and  where  are  they 
located? 

How  many  nodes  were  not  affected  in 
the  damaged  area  that  the  model 
predicted  would  be? 

Other  questions  that  the  GIS  could 
answer. 

If  Node  A  is  restored,  how  many  other 
nodes  will  be  reconnected? 

The  primary  interface  for  the  user  and  GIS  will  be  pointing  devices  to 
dynamically  define  and  adjust  the  geographic  area  of  interest.  For  example,  during  an 
earthquake  recovery  effort,  the  EMT  could  identify  the  affected  area  by  selecting  an 
2q)propriate  map  area,  save  it  as  a  default  and  then  proceed  to  analyze  the  situation  as 
information  becomes  available.  If  requested  to  supply  some  form  of  satellite  feed  to  a 
site,  the  EMT  could  query  the  DBMS  through  the  GIS  to  "show  all  satellite  groimd 
stations  within  three  miles,"  or  "list  all  sites  that  utilize  the  damaged  satellite  dish." 

3.  Considerations  in  GIS  Selection 

The  efficient  use  of  a  GIS  rests  critically  on  the  proper  structuring  of  the 
underlying  database.  Consideration  must  be  given  to  how  the  data  is  input,  accessed. 
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modified,  maintained,  and  its  frequency  of  use.  Security  issues  such  as  separate  layers 
for  the  communications  assets  of  ATT,  MCI  and  other  vendors  must  be  addressed.  Will 
security  requirements  dictate,  or  be  subjugated  to,  performance  requirements?  "It  is 
difficult  to  overstress  the  importance  of  adequately  documenting  the  database  design  and 
subsequent  implementation  efforts."  (Chambers,  1989) 

Additionally  GIS  features  should  be  evaluated  with  respect  to  TEDSS  n 
requirements,  as  commercial  GIS’s  may  possess  more  features  than  can  be  utilized  by 
TEDSS  n.  Many  GISs,  such  as  MapGraphix,  support  data  presentation  methods  which 
TEDSS  currently  does  not  support.  If  this  is  the  case,  perhaps  system  performance  can 
be  improved  by  developing  a  custom  GIS  with  only  the  requisite  features  included,  or 
implemented  by  a  developer  with  products  such  as  TerraView. 

C.  DATA 

The  current  TEDSS  database  consists  of  approximately  thirty  megabytes  of 
communications  system  information.  However,  TEDSS  does  not  present  the  information 
in  a  very  usable  fashion  and  poor  performance  is  a  problem.  TEDSS  has  consistently 
provided  slow  response  to  even  the  simple  preprogrammed  queries.  Short  and  Bockenek 
(1989,  p.  105)  identified  several  areas  in  TEDSS  where  simple  changes  to  the  INGRES 
database  access  and  structure  procedures  resulted  in  40-90%  improvement  of  processing 
speed.  During  my  use  of  TEDSS,  a  query  to  identify  all  nodes  in  the  state  of  Virginia 
took  in  excess  of  15  minutes  to  execute.  Users  expect  better  response  times,  especially 
from  a  system  to  support  emergency  management. 
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The  current  TEDSS  database  appears  to  be  poorly  designed.  Because  TEDSS  does 
not  allow  freeform  queries,  those  queries  which  are  supported  should  have  been  optimized 
for  quick  response.  Short  and  Bockenek  (1989)  identified  several  deficiencies  in  their 
limited  review  of  the  TEDSS  DBMS  that  imply  the  DBMS  designers  were  not  proficient 
in  coding.  While  the  continued  lack  of  a  data  dictionary  or  documented  database  schema 
for  TEDSS  indicates  that  overall  database  maintenance  has  not  been  a  priority. 

TEDSS  n  will  require  the  use  of  a  database  to  support  other  components  of  the 
system.  Several  data  requirements  and  analysis  steps  are  necessary  to  implement  the 
database  and  to  address  the  current  deficiencies  in  data  management.  Presently  the 
National  NCS  Office  is  responsible  for  incorporating  changes  to  the  TEDSS  database  and 
distributing  updates.  However  no  full  time  Database  Administrator  (DBA)  to  monitor 
both  the  quality  and  accuracy  of  the  data  is  presently  assigned.  Although  NCS  is 
currently  in  the  process  of  hiring  a  DBA,  a  structured  method  of  validation  and 
maintenance  of  the  TEDSS  database  should  be  addressed.  The  worst  time  to  identify 
errors  or  omissions  in  the  database  would  be  during  a  crisis. 

Three  options  to  provide  the  required  database  management  system  (DBMS) 
capabilities  in  TEDSS  will  be  considered. 

1.  Maintain  the  lease  of  the  existing  INGRES  database  system,  and  have  TEDSS  continue 
to  utilize  the  present  database. 

2.  Develop  a  custom  DBMS  using  C  or  other  programming  language,  and  convert  the 
existing  database  to  the  new  DBMS. 

3.  Purchase,  rather  than  lease,  a  DBMS  developed  for  the  targeted  hardware  platform  and 
convert  the  existing  database  to  the  new  DBMS. 
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The  first  option  to  utilize  the  existing  INGRES  database  in  TEDSS  II  offers  the 
cheapest  option  for  initial  acquisition,  but  will  not  be  the  most  cost  effective  solution  on 
a  long  term  basis.  INGRES  was  initially  developed  for  use  on  mini  and  mainframe 
computers;  in  the  process  of  downsizing  the  system  to  operate  on  a  PC,  significant 
performance  problems  occur.  The  extensive  overhead  inherent  in  a  large  DBMS  such  as 
INGRES  extracts  a  performance  penalty  on  TEDSS  and  offers  many  capabilities  that  will 
not  be  utilized  in  TEDSS. 

The  policy  of  leasing  UNIX  applications  on  an  annual  basis  instead  of  purchasing 
a  limited  lifetime  license  for  the  program  and  paying  for  all  subsequent  program  updates 
developed  is  not  cost  effective.  The  INGRES  program  offers  little  if  any  functional 
improvements  from  many  commercial  products  that  may  be  purchased  without  having  to 
pay  onerous  annual  lease  costs.  A  life  cycle  saving  of  many  thousands  of  dollars  will 
result  from  purchasing  rather  leasing  the  DBMS. 

The  second  option  to  develop  a  custom  DBMS  to  support  TEDSS  will  offer  the  best 
performance  but  will  be  the  most  expensive  in  terms  of  development  and  life  cycle 
maintenance  costs.  TEDSS  currently  is  not  expected  to  possess  any  unique  data 
requirements  that  are  not  met  by  dozens  of  commercial  available  DBMSs.  A  custom 
DBMS  requires  a  significant  amount  of  time  and  money  to  develop  in  return  for  a 
relatively  small  gain  in  speed.  A  significantly  larger  gain  in  speed  per  dollar  of 
investment  would  be  obtained  by  fully  normalizing  the  data  relationsh^s  in  TEDSS  and 
optimizing  data  t;torage  mechanisms  to  improve  retrieval  speed. 


43 


The  third  method  of  purchasing  rather  than  leasing  a  DBMS  offers  both  the  most 
cost  effective  option  and  maximum  flexibility  for  TEDSS.  While  the  DBMS  selected  to 
replace  INGRES  must  operate  on  the  target  operating  system,  in  many  cases,  it  may  be 
picked  independently  of  the  operating  system  as  most  major  DBMS  offer  peer  compatible 
versions.  Oracle,  Ashton  Tate,  Fox  and  others  offer  DBMSs  that  can  operate  in  UNIX, 
DOS  and  Macintosh  operating  systems. 

The  present  INGRES  database  offers  a  rich  assortment  of  capabilities  appropriate 
for  a  mini-computer.  Suppon  for  multiple  users,  concurrency  control,  data  locking,  and 
other  data  sharing  features  which  are  not  currently  utilized  by  TEDSS  may  be  a 
significant  cause  of  the  performance  problems  associated  with  TEDSS.  Consideration 
should  be  given  to  using  databases  which  have  been  developed  for  single  user,  single¬ 
tasking  PCs.  While  they  lack  some  of  the  more  elaborate  data  integrity  abilities 
characteristic  of  multiple  user  DBMS,  they  provide  a  more  optimized  performance  for  the 
PC  environment  such  as  FoxPro,  and  Paradox.  Unless  the  type  or  amount  of  data,  or  the 
number  of  concurrent  users  increases  significantly  TEDSS  will  not  be  able  to  utilize  the 
majority  of  INGRES  or  other  mini-computer  database  features,  and  will  continue  to  suffer 
a  performance  penalty  from  this  unused  overhead. 

Whatever  database  is  selected  should  support  the  ANSI  Structured  Query  Language 
(SQL)  interface.  This  standard  query  method  will  offer  a  consistent  external  interface  to 
the  user,  and  not  unnecessarily  tie  TEDSS  to  a  specific  DBMS. 
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D.  MODELS 


The  model  section  of  TEDSS  currently  contains  only  the  Damage  Assessment 
model.  As  additional  models  are  developed  and  validated  they  would  be  incorporated  into 
TEDSS  n.  The  XTRAM  model  should  be  examined  to  determine  if  the  knowledge  rules 
developed  are  valid.  If  so,  the  rules  and  information  from  XTRAM  shotild  be  transferred 
to  TEDSS.  The  Department  of  Defense,  Federal  Emergency  Management  Agencies  and 
other  Federal  Agencies  should  be  investigated  for  models  that  could  assist  in  emergency 
management.  If  practical  models  are  found,  they  should  be  adapted  for  use  in  TEDSS, 
rather  than  developing  them  independently. 

All  models  regardless  of  source  should  be  modified  to  adjust  to  the  GUI  interface 
standards  and  ensure  that  all  data  is  accessed  from  the  DBMS  and  not  hidden  within  the 
model.  When  model  interaction  involves  spatial  information,  the  information  by  default 
should  be  interfaced  through  the  GIS. 

E.  OTHER  COMPONENTS 

Voice  recognition  offers  the  capabilities  today  to  enhance  EMT  performance  with 
TEDSS.  People  communicate  verbally  at  two-hundred  words  per  minute  yet  few  people 
type  better  than  sixty  words  per  minute.  Studies  have  shown  that  people  work  more 
effectively  when  using  more  of  their  sensory  skills.  Presently  TEDSS  utilizes  the  users’ 
tactile  (hands)  and  limited  visual  senses  to  input  or  process  information.  TEDSS  n  will 
emphasize  the  visual  by  increasing  graphics,  and  simplify  tire  remaining  tactile 
requirements  by  using  voice  recognition.  Voice  recognition  allows  the  user  to  tell  the 
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machine  the  desired  action  without  having  to  translate  commands  into  keystrokes.  As 
members  of  the  EMT  will  not  normally  be  .skilled  typists,  the  ability  to  instruct  the 
machine  verbally  should  allow  quicker  control  and  less  entry  errors,  and  permit  the  EMT 
to  be  doing  other  tasks  concurrently  with  TEDSS  operations.  (Lee,  Hauptmann  and 
Rudnicky,  1990,  p.  225). 

Voice  recognition  is  not  the  same  as  a  natural  language  interface.  The  computer 
responds  to  recognized  verbal  commands  in  a  pre-programmed  maimer  rather  than 
translating  sentence  intention.  The  computer  does  understand  the  phonetic  difference 
between  the  words  "up"  and  "down,"  however  it  translates  only  in  the  sense  that  the  word 
"up"  signifies  a  specific  keystroke  and  "down"  a  different  keystroke.  For  example,  a 
product  called  the  Voice  Navigator  II  for  the  Apple  Macintosh  computer  can  be  trained 
to  recognize  several  thousand  different  commands  for  each  user.  The  Voice  Navigator 
will  allow  the  user  to  open  a  file,  edit,  move  or  delete  text  and  graphics,  then  save  the 
file  without  touching  the  keyboard.  The  system  may  be  trained  to  simulate  any  command 
or  keystroke.  TEDSS  could  use  this  ability  to  allow  the  EMT  to  open  a  window,  display 
a  map  of  the  region,  zoom  in  to  a  specific  state,  and  simulate  the  effect  of  a  bomb  blast 
and  identify  all  networks  that  will  be  affected  in  a  thirty  mile  radius  without  ever 
touching  the  keyboard. 

F.  SUMMARY 

This  chapter  has  addressed  the  major  components  of  the  proposed  system.  TEDSS 
II  should  be  considered  an  evolving  system  able  to  support  future  missions  by  utilizing 
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emerging  technology  to  enhance  the  decision  making  process.  By  the  effective  use  of  a 
GUI  and  GIS,  users  should  be  able  to  generate  interactively  queries  and  information 
presentations  that  allow  them  to  ’see’  what  is  transpiring  instead  of  having  to  derive  this 
information  from  reviewing  voluminous  data  retrievals  and  printouts.  The  user  will 
decide  the  level  of  detail  to  view  in  data  presentation.  TEDSS  II’s  use  of  a  GUI  allows 
the  user  to  define  a  window  to  view  desired  information  and  select  the  presentation 
format  as  text  from  the  database,  or  to  have  it  translated  into  a  graphic  image  by  the  GIS. 
Further  TEDSS  11  should  ideally  allow  the  EMT  to  complete  a  major  portion  of  their 
work  through  voice  interaction  instead  of  requiring  the  use  of  the  keyboard. 

TEDSS  n  should  be  developed  and  managed  to  meet  these  goals  and  not  be 
restrained  from  adopting  new  software  or  hardware  when  appropriate.  The  following 
chapter  will  address  software  management  issues  that  affect  future  development. 
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V.  FUTURE  SOFTWARE  CONSIDERATIONS 


This  chapter  reviews  several  project  management  issues  in  the  TEDSS  n  program 
relating  to  Life  Cycle  Management  (LCM)  and  development  costs.  The  focus  is  on 
critical  management  issues  that  should  be  decided  or  evaluated  prior  to  initiating 
development  of  subsequent  TEDSS  implementations. 

A.  LIFE  CYCLE  MANAGEMENT 

TEDSS  has  struggled  to  fulfill  a  changing  role  in  emergency  communications 
management.  The  system  was  developed  initially  to  manage  the  large  amount  of 
communications  assets  in  the  early  1980s.  As  with  similar  computer  systems  of  the 
period,  the  computer  was  considered  more  of  an  electronic  filing  cabinet  than  a  tool  to 
support  decision  making.  As  the  TEDSS  program  evolved  to  meet  the  EMT’s 
requirements  and  the  changing  needs  of  the  organization,  the  improvements  have  been 
disjointed  and  do  not  appear  to  follow  a  coordinated  development  plan  or  overall  goal 
beyond  elimination  of  immediate  problems. 

TEDSS  II  needs  to  undergo  a  complete  requirements  evaluation  and  determination 
of  system  goals  prior  to  developing  a  follow-on  system.  The  existing  TEDSS  serves  a 
valuable  role  as  a  prototype  that  has  educated  both  users  and  management  to  the 
capabilities  and  limitations  of  computer  assisted  emergency  management.  But  if  TEDSS 
II  is  to  fulfill  both  current  requirements  and  serve  as  a  platfomi  for  future  growth,  the 
organization’s  long  term  goals  for  TEDSS  must  be  established. 
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B.  LONG-TERM  SYSTEM  GROWTH/GOALS 


Computers  currently  impact  almost  every  segment  of  our  lives,  and  society  is 
becoming  increasingly  more  dependent  on  them  to  support  and  improve  the  quality  of  life. 
Advances  in  artificial  intelligence  (AI)  and  DSSs  continue  to  produce  virtual  machines 
that  can  handle  increasingly  complex  tasks  dependably  and  reliably.  As  the  number  of 
computers  have  increased,  the  amount  of  data  created,  moditied  and  transmitted 
electronically  has  exploded.  Computer  networks  spanning  the  nation  are  utilized  daily 
and  must  be  maintained  at  all  times  to  keep  the  data  flowing  reliably  TEDSS’  goal  to 
support  the  maintenance  of  certain  networks  will  continue  to  increase  in  importance  in 
the  future.  While  overt  military  and  terrorist  actions  become  less  likely,  natural  disasters 
will  always  present  possibilities  for  rapid  destruction  of  communication  assets.  Therefore, 
in  planning  TEDSS  future,  the  overall  NCS  mission  should  be  evaluated  to  determine 
what  critical  tasks  and  missions  must  be  maintained,  the  information  they  require,  and  the 
sources  of  the  information  to  establish  a  set  of  long  term  goals  for  TEDSS. 

The  TEDSS  platform  can  offer  the  EMT  many  tools  to  provide  effective  decision 
management,  if  and  only  if,  TEDSS  has  correct  and  accurate  information.  While  not 
privy  to  the  exact  data  types,  formats  and  structures  provided  by  communication  vendors 
such  as  ATT  and  MCI,  the  style,  content,  quality  and  future  access  to  the  information  will 
affect  TEDSS  long  term  goals.  If  TEDSS  is  unable  to  obtain  current  information  about 
communication  assets  from  commercial  vendors,  the  goals  and  use  of  TEDSS  will  be 
subverted. 
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C.  USEABILITY  AND  ADAPTABILITY 

TEDSS  n  must  be  useable  and  adaptable  to  each  individual  EMT  member  to  allow 
the  maximum  effective  use  of  TEDSS  II.  The  GUI  will  allow  the  user  to  adapt  and 
customize  displays  in  many  fonns,  to  maintain  multiple  windows,  to  set  default 
parameters,  to  vary  fonts,  and  to  screen  color  selections.  However,  the  users’  ability  to 
customize  is  a  mixed  benefit  to  TEDSS  n.  A  structured  interface  provides  a  standard 
environment  to  which  everyone  may  become  acclimated,  but  it  may  also  artificially 
restrict  the  user’s  method  of  problem  solving  much  like  TEDSS  present  menu  interface 
does.  On  the  other  hand,  the  user’s  ability  to  endlessly  customize  screens  may  also 
complicate  the  expected  emergency  management  scenarios  in  which  multiple  users  operate 
the  system  continuously  until  the  emergency  situation  is  resolved.  This  dilemma  is 
similar  to  a  shared  desk  in  an  office.  When  a  worker  is  restricted  in  the  location  and 
arrangement  of  items  on  the  desktop  it  may  be  easier  for  others  to  find  things  on  his  desk, 
but  at  the  cost  of  constraining  his  use  of  the  desk  (menus).  However,  if  no  rules  are 
relied  to  desktop  arrangement  when  that  worker  is  relieved  (e.g.  when  the  EMT  changes 
shift),  the  substitute  will  require  time  to  acclimate  to  the  existing  desktop  condition  until 
it  is  modified  to  an  arrangement  that  is  efficient  for  him.  Thus  there  is  a  tradeoff 
between  flexibility  and  efficiency. 

This  conflict  between  the  need  to  customize  the  interface  and  maintain  standards 
can  be  solved  by  allowing  the  user  to  define  his  workspace.  TEDSS  users  should  be  able 
to  dynamically  define  and  adjust  window  size,  color,  and  location  and  then  save  these 
screen  profiles  for  later  retrieval.  Users  would  then  be  able  to  define,  save  and  recall  a 
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work  environment  without  imposing  that  environment  on  other  users.  TEDSS  could  also 
define  several  environment  templates  which  would  serve  as  reference  points  for  a  new 
user  imtil  he  can  determine  the  screen  design(s)  that  best  supports  his  work.  For  example 
a  default  setup  for  the  tracking  of  hurricanes  could  be  established  and  maintained  in 
TEDSS.  Novice  users  could  use  the  predefined  screen  initially  and,  as  they  become  more 
sophisticated,  modify  it  to  accommodate  personal  preferences. 

The  ability  to  configure  the  screen  and  other  system  components  should  be 
addressed  early  in  development.  Each  TEDSS  user  should  probably  develop  a  personal 
dataset  composed  of  screen  configurations,  default  options,  screen  colors  and  voice 
recognition  files  that  comprise  the  unique  elements  of  his  work  environment.  If  the 
dataset  is  maintained  by  the  user  in  a  manner  similar  to  an  identification  card,  he  may 
then  go  to  any  TEDSS  n  system,  insert  the  dataset  of  preferences,  and  immediately 
recreate  his  preferred  work  environment. 

D.  SYSTEM  ADMINISTRATION  AND  MAINTENANCE 

TEDSS  n  will  require  a  shift  in  program  administration  which  should  offer  a  good 
starting  point  to  modify  the  software  development  methods  to  reduce  overall  system  costs. 

TEDSS  presently  has  a  program  and  project  manager,  but  does  not  appear  to  have 
any  one  person  responsible  for  the  daily  administrative  work  and  maintenance  of  the 
system.  Additionally  the  National  office  is  responsible  for  database  maintenance  and 
updates  back  to  the  regional  component,  however  no  full  or  part  time  database 
administrator  is  utilized.  Emergency  management  should  not  be  assigned  as  a  part  time 
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task,  without  some  alternative  method  of  assessing  the  system’s  ability  to  handle  the 
emergency,  as  it  will  only  be  during  the  times  of  crisis  that  omitted  actions  will  be 
identified.  The  simulations  and  training  conducted  by  NCS  serve  to  validate  the  TEDSS 
database,  only  if  the  accuracy  of  data  is  truly  verified,  and  those  steps  that  d^nd  on  the 
accuracy  of  the  information  are  not  artificially  executed. 

As  outlined  in  the  previous  sections,  NCS  must  establish  the  goals  for  TEDSS, 
develop  a  prototype  of  TEDSS  n,  and  iteratively  refine  TEDSS  n  towards  the  system 
goals.  TEDSS,  like  the  emergency  management  situations  it  is  designed  to  support,  will 
always  be  in  a  state  of  change.  As  TEDSS  improves,  the  EMT’s  expectations  will  grow 
accordingly.  The  initial  version  of  TEDSS,  while  coming  to  the  end  of  its  useful  life,  has 
successfully  introduced  the  EMT  to  a  computerized  decision  aid.  The  NCS  should 
harness  the  knowledge  of  its  users  in  the  development  of  TEDSS  n  initial  requirements, 
and  deteimine  what  areas  to  stress  in  the  upgrades  after  the  initial  fielding.  The  NCS 
simulations  and  training  exercises  offer  a  splendid  opportunity  to  solicit  real-time 
feedback  on  system  requirements  and  deficiencies.  Since  the  final  capabilities  of  TEDSS 
will  depend  on  the  data  it  can  access,  it  may  be  prudent  to  involve  the  commercial 
vendors  which  will  ultimately  supply  the  data. 

Sections  of  TEDSS  has  been  implemented  in  various  programming  languages 
including  C,  Fortran,  and  assembler  while  using  an  undetermined  software  methodology. 
If  TEDSS  n  is  viewed  as  an  opportunity  to  start  over  using  the  ideas  developed  in  the 
initial  prototype,  several  softwaie  development  methodologies  should  be  considered. 
These  would  provide  a  solid  base  for  the  evolutionary  enhancement  of  TEDSS.  Computer 
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aided  software  engineering  (CASE)  tools  and  object-oriented  design  and  programming 
may  offer  methods  to  decrease  development  cost  while  providing  more  implementation 
flexibility  over  the  TEDSS  n  system  life. 

CASE  tools  automate  and  structure  the  translation  of  system  requirements  into 
software.  They  assist  in  establishing  and  maintaining  the  database  and  an  associated  data 
dictionary,  and  when  used  with  code  generators,  can  automate  the  generation  of  software 
to  support  the  interconnection  of  different  components  in  TEDSS. 

Object  Oriented  Analysis  and  Programming  (OOA/OOP)  has  been  touted  as  a 
solution  to  the  software  maintenance  problem.  OOA/OOP  is  a  paradigm  shift  in  software 
development  from  what  a  process  does  to  what  the  functional  parts  of  the  program  are. 
Although  it  remains  to  be  seen  whether  OOP/OOA  will  solve  the  significant  cost  and 
manpower  problems  associated  with  software  maintenance,  it  does  offer  a  way  to  reduce 
costs. 

The  change  in  focus  from  processes  to  objects  makes  the  initial  development  of  an 
object-oriented  design  more  difficult  and  expensive.  However,  once  designed,  the  objects 
can  be  reused  in  future  software  development  efforts  resulting  in  lower  development  costs 
in  follow  on  use.  OOA/OOP  defines  everything  as  objects  and  requires  all  objects  to 
communicate  by  messages  with  other  objects.  Preventing  objects  from  accessing  other 
objects’  code  directly  allows  the  internal  workings  of  an  object  to  be  modified  without 
affecting  the  larger  system’s  opieration.  This  ability  to  change  or  enhance  the  internal 
functions  of  objects  without  affecting  their  external  behavior  results  in  a  major  reduc  tion 
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in  system  maintenance  costs.  Many  GUIs  are  provide  an  object-oriented  environment, 
however  they  may  not  have  bee  implements  using  object-oriented  methodologies. 

Although  OOA/OOP  may  be  effective  in  the  reduction  of  software  life  cycle  costs, 
it  may  not  bring  cost  savings  initally  to  TEDSS.  The  lowered  life  cycle  costs  normally 
come  from  the  reuse  of  previously  defined  objects  in  later  projects.  Since  TEDSS  will 
probably  be  a  stand  alone  project,  the  ability  to  reuse  modules  may  not  arise.  However, 
OOP  may  decrease  the  total  maintenance  effort  over  TEDSS  n  life.  If  additional  models 
are  developed  for  TEDSS  they  may  be  able  to  utilize  OOA/OOP  concepts  by  reusing 
objects  from  previous  models.  This  is  especially  true  with  respect  to  displaying  the 
effects  of  a  model  on  the  GIS  maps. 

E.  OPERATING  SYSTEMS 

1.  Multi-tasking  and  Multi-threading  Requirements  of  Operating  Systems 
The  GUI  places  a  significant  load  on  the  operating  system.  It  allows  several 
applications  to  be  operating  simultaneously  and  must  manage  the  possibility  of  one 
program  modifying  data  another  program  is  utilizing  concurrently.  These  non-trivial 
requirements  ca;:  b?  satisfied  by  use  of  hardware  and  software  configured  in  several  ways 
of  increasing  complexity: 

1.  Context  switching 

2.  Multi-tasking 

a.  Pre-emptive  multi-tasking 

b.  Time-sliced  multi-tasking 
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c.  Cooperative  multi-tasking 
3.  Multi-tasking  with  multi-threading 

The  following  will  attempt  to  illustrate  the  subtle  but  significant  difference  between 
operating  system  capabilities. 

Context  switching  occurs  when  several  programs  are  loaded  into  memory  and 
the  user  alternates  between  applications.  However,  only  one  q>plication  is  operating  in 
the  central  processing  unit  (CPU)  at  a  time,  with  the  user  determining  which  process  is 
active. 

Multi-tasking  occurs  when  several  programs  are  loaded  into  memory 
simultaneously  and  are  rapidly  switched  into  and  out  of  the  CPU  so  that  it  appears  to  the 
users  that  all  tasks  are  ruiming  towards  completion.  Multi-tasking  comes  in  a  range  of 
flavors  of  decreasing  robustness:  pre-emptive,  time-sliced  and  cooperative. 

Pre-emptive  multi-tasking  occurs  when  one  process  may  ’preempt’  or  bump 
another  process  because  it  has  a  higher  priority.  In  time-sliced  each  process  will  get  an 
equal  share  of  the  time  with  the  CPU  regardless  if  they  can  use  it  or  not.  In  cooperative 
multi-tasking  however,  each  process  gets  the  CPU  for  an  equal  amount  of  time,  but  uses 
the  CPU  only  as  long  as  it  needs  it.  Each  process  ’cooperates’  by  giving  the  CPU  up 
•  when  it  is  waiting  for  other  functions  maximizing  CPU  use.  Multi-tasking  operating 

systems  come  in  many  subtle  flavors  from  these  broad  categories  listed,  but  the  basic 
concepts  of  operation  are  similar. 
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Multi-threading  is  the  ability  of  a  process  to  be  executed  several  times 
concurrently,  using  the  same  code  segments  in  memory  with  a  multi-tasking  operating 
system.  The  primary  advantage  of  multi-threading  is  the  economical  utilization  of 
memory  space.  Multiple  users  or  processes  can  use  the  same  segment  of  memory  without 
loading  multiple  copies  of  the  program.  A  common  example  of  multi-threading  is  word 
processing  software  on  a  mini  or  mainframe  computer,  several  users  can  be  editing 
documents  simultaneously  in  the  word  processor.  The  operating  system  has  only  one 
copy  of  the  program  running  and  tracks  what  section  of  the  software  each  user  is  in. 
TEDSS  could  use  multi-threading  when  several  views  of  a  situation  were  required 
simultaneously  using  a  GIS.  Each  view  could  be  maintained  concurrently  as  data  changed 
and  updated  allowing  multiple  models  to  be  forecasting  concurrently,  with  a  decreased 
drain  on  system  resources. 

It  is  interesting  to  note  that  TEDSS  currently  operates  in  a  context  switching 
mode  since  only  TEDSS  or  Mapinfo  may  be  used,  however  it  is  operating  on  a  multi¬ 
tasking  operating  system,  UNIX.  This  indicates  that  TEDSS  is  not  currently  using  the 
full  capabilities  of  UNIX.  This  underscores  the  need  for  an  investigation  of  the  true 
requirements  of  TEDSS. 

2.  GUIs  and  Operating  Systems 

The  current  TEDSS  utilization  of  two  operating  system  environments 
unnecessarily  complicates  the  programming  and  system  maintenance  environment. 
TEDSS  n  should  determine  the  best  operating  system  for  its  needs  and  utilize  only  that 
operating  system.  As  stated  earlier,  the  operating  system  and  the  GUI  are  intimately 
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entwined,  and  one  can  not  really  be  separated  from  the  other.  Some  operating  systems 
actually  are  inseparable  from  the  GUI  as  in  the  case  of  the  Apple  Macintosh,  while  others 
are  simply  a  shell,  albeit  a  complicated  one,  such  as  Microsoft  Windows  (WINS)  and  X- 
Windows,  they  insulate  the  user  from  the  operating  system  complexities  and 
idiosyncracies. 

While  the  Macintosh  has  been  a  commercial  product  for  almost  ten  years, 
most  GUIs  have  only  become  commercially  available  with  software  applications  in  the 
last  four  or  five  years.  Currently  several  platforms  have  begim  offering  applications 
which  will  allow  a  GUI  designed  for  one  platform  to  operate  as  a  process  on  another 
platform.  For  example.  Sun  Microsystems  offers  a  MOTIF  Shell  that  will  allow  a  UNIX 
workstation  to  run  MS  Windows  applications.  However,  not  all  combinations  are 
available.  Attempting  to  synthesize  GUIs  and  operating  systems  to  attain  the  best  of  all 
worlds  may  eventually  lead  to  a  loss  of  standards  and  undesirable  complications.  The 
following  will  discuss  the  major  operating  systems  and  the  graphical  shells  they  support. 

3.  Personal  Computer  Disk  Operating  System  (PC-DOS) 

PC-DOS  and  Microsoft  Windows  Version  3.0  (WIN3)  may  be  the  largest  (in 
volume)  commercial  software  products  in  the  marketplace^.  DOS  was  developed  for  the 
IBM  Personal  Computer  in  1981  as  a  single-user,  single-tasking  operating  system  for 
stand  alone  Personal  Computer  (PC).  The  current  commercial  version  5.0  offers  many 


^The  product  Personal  Computer  Disk  Operating  System  (PC-DOS),  or  Microsoft  Disk 
Operating  System  (MS-DOS),  or  DOS  will  be  used  synonymously,  as  the  difference  in 
names  is  due  to  marketing  and  trademarks,  and  not  a  difference  in  technical  capabil-ries. 
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evolutionary  enhancements,  but  the  operating  system  in  general  has  some  significant 
problems.  DOS  imposes  restrictions  on  program  segment  size  which  prevents  programs 
from  effectively  or  efficiently  using  all  memory  present.  This  finequently  necessitates 
programming  ’tricks’  to  accomplish  the  desired  functions.  Problems  such  as  non-linear 
memory  models,  no  memory  partitions,  are  technical  in  nature  but  the  effects  are 
noticeable  to  the  users  in  the  form  of  performance  penalties. 

Whereas  DOS  is  a  single  task  operating  system,  several  commercial  software 
products  are  sold  to  permit  DOS  to  perform  as  multi-tasking  operating  system.  WIN3  and 
Quarterdeck’s  DESQview  (DV)  are  examples  of  products  which  simulate  a  simple  multi¬ 
tasking  environment  allowing  multiple  applications  to  operate  concurrently.  However,  all 
of  these  products  are  not  as  robust  as  a  true  multi-tasking  operating  system.  If  a  process 
fails  in  DV  or  WIN3,  it  may  cause  all  other  processes  to  terminate.  Because  WIN3  and 
DV  do  not  have  complete  control  of  the  environment,  they  must  ultimately  depend  on 
DOS  for  some  functions. 

4.  Apple  Macintosh 

The  MAC  allows  several  applications  to  be  loaded  into  memory 
simultaneously  but  currently  offers  only  cooperative  multi-tasking.  The  current  version, 
Apple  System  7.0,  has  improved  networking  abilities,  and  supports  the  dynamic  linking 
of  processes  through  Apple  events. 

MAC’S  use  of  cooperative  multi-tasking  means  overall  system  performance 
will  be  no  better  than  the  worst-written  program.  The  MAC,  like  WIN3,  depends  on  a 
program  to  give  up  its  processor  time  when  waiting  for  an  event  such  as  a  key  press  to 
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complete.  If  the  program  does  not  relinquish  its  time,  the  central  processor  unit  (CPU) 
will  sit  idle.  Therefore,  if  programs  are  written  efficiently  to  use  only  the  CPU  time 
required,  every  process  will  run  as  fast  as  possible. 

5.  IBM  Operating  Systeni/2  (OS/2) 

»  OS/2  is  a  fiilly  functional  multi-tasking,  multi-threaded  operating  system. 

Developed  jointly  by  IBM  and  Microsoft,  OS/2  was  intended  to  replace  DOS,  and  serve 
as  the  primary  operating  system  on  80286  and  higher  Intel  microprocessors.  Initially  an 
operating  system,  it  is  now  similar  to  the  MAC  in  that  there  is  a  blurry  boundtuy  between 
the  operating  system  and  the  GUI.  While  OS/2  has  not  enjoyed  widespread  market 
success  and  suffers  from  a  limited  selection  of  applications,  it  has  made  significant 
inroads  into  specific  segments  of  computer  users.  OS/2  is  used  as  the  operating  system 
of  choice  in  local  area  network  (LAN)  servers  due  to  its  high  speed  file  system  (HPFS) 
and  programmed  support  of  networks.  The  HPFS  offers  between  30  and  400  percent 
improvement  in  file  access  times  compared  to  DOS  using  the  same  hardware.  (Heller, 
1990,  p.  168). 

Version  2.0  of  OS/2  is  currently  in  advanced  beta  testing  and  is  expected  to 
be  released  by  the  end  of  1991.  It  has  been  promoted  by  IBM  as  "a  better  EKDS  than 
DOS  and  a  better  Windows  than  Windows."  (Davis,  1991,  p.  106).  It  is  annotated  that 
version  2.0  will  be  able  to  multi-task  OS/2  specific  programs  with  MS  Windows  3.0  and 
“  DOS  programs. 

OS/2’s  ability  to  support  pre-emptive  multi-tasking  and  multi-threaded 
processes,  as  well  as  to  maintain  a  ’flat’  32-bit  memory  model  addresses  many  of  DtjS’s 
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shortcomings,  with  only  a  small  decrease  in  single  task  performance.  All  multi-tasking 
operating  systems  carry  a  fixed  amount  of  overhead  that  single  task  operating  system  do 
not.  Therefore  when  running  a  single  process,  DOS  may  still  be  quicker  than  OS/2, 
however  OS/2’s  wider  data  bus  and  quicker  file  access  methods  may  eventually  make  it 
a  "better  DOS  than  DOS." 

The  latest  release  of  OS/2,  version  1.3,  can  operate  DOS  tqjplications  with  few 
limitations.  Furthermore,  should  an  application  terminate  unexpectedly,  it  wiU  not  affect 
any  other  application  because  OS/2  has  segmented  memory  to  prevent  one  process  from 
destroying  another  in  memory.  This  feature  makes  OS/2  desirable  for  certain  kinds  of 
applications:  "’mission-critical’  applications  always  crop  up  in  discussions  of  OS/2.  It’s 
rock  solid."  (UdeU,  1991,  p.  98). 

OS/2’s  lack  of  software  applications  base  has  not  prevented  it  from  often 
serving  as  a  platform  for  developing  DOS  applications.  Several  CASE  and  programming 
tools  for  DOS  and  mainframe  envirorunents  are  available  for  OS/2  because  it  can  simulate 
multiple  DOS  sessions  and  provide  graceful  degradation  when  an  application  aborts. 
Additionally,  OS/2  similarities  to  UNIX  offers  a  migration  path  for  developers  attempting 
to  port  applications  from  Workstations  to  DOS.  OS/2  serves  as  an  intermediary  platform 
in  this  process.  (Nicholls,  1990,  p.  164) 

6.  UNIX 

UNIX  is  a  venerable  operating  system  that  has  been  in  use  for  over  twenty 
years.  It  operates  on  almost  every  hardware  platform  commercially  available.  Uf'JIX 
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provides  solid  performance  in  a  time-sliced  pre-emptive  multi-tasking,  multi-user,  multi¬ 
threading  operating  system. 

The  UNIX  operating  system  developed  at  Bell  Laboratories  was  never 
intended  to  be  a  commercial  product,  but  rather  an  internal  laboratory  computer  operating 
system.  The  system  became  a  commercial  product  more  by  default  than  design,  and 
comes  in  many  subtle  flavors,  such  as  ATT  UNIX  and  Santa  Cruz  Operations  UNIX. 
These  flavors  are  not  equivalent;  while  the  basic  concepts  are  the  same,  commands  and 
other  differences  affect  compatibility.  While  UNIX  is  powerful  at  the  operating  system 
level,  it  is  not  user  friendly  because  of  cryptic  and  non-intuitive  commands. 

7.  Comparison  of  Operating  Systems 

The  relative  value  of  the  operating  system  is  directly  related  to  the  tasks  it 
will  be  performing.  TEDSS’  dependence  on  graphical  presentations  with  multiple  data 
views  indicates  that  some  form  of  multi-tasking  is  required.  The  emergency  nature  of  its 
task  implies  that  the  system  must  be  stable  and  not  prone  to  failure.  These  following 
requirements  would  indicate  that  OS/2  or  UNIX  would  be  ‘he  preferable  platforms.  The 
Mac  could  also  be  a  viable  platform  if  the  increased  multi-tasking  capabilities  supported 
in  System  7.0  are  utilized  in  applications  used  in  TEDSS.  MS  Windows  3.0  (WIN3), 
while  commercially  successful,  is  susceptible  to  unusual  and  unexpected  failures  related 
to  both  hardware  incompatibilities  and  interaction  with  DOS. 

If  the  GUI’s  requirements  for  ease  of  use,  availability  of  applications,  and 
development  tools  were  the  primary  considerations,  a  subjective  evaluation  would  place 
the  Macintosh  first,  followed  by  WIN3,  UNIX,  and  OS/2.  Macintosh’s  well-developed 
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and  tested  GUI  is  extremely  consistent  across  its  broad  range  of  applications  which  are 
normally  more  powerful  than  the  current  WIN3  applications. 

F.  TEDSS  SECURITY  REQUIREMENTS 

A  major  issue  for  TEDSS  is  system  security.  No  clear  cut  delineation  of  overall 
security  requirements  was  found  in  TEDSS  documentation. 

Individually,  records  in  the  EPMIS  [TEDSS]  data  base  are  not  considered  to  be 
classified;  however,  the  entire  collection  of  data  is  treated  as  SECRET.  Industry 
data  in  the  data  base  is  considered  as  proprietary.  (Booz,  Allen  and  Hamilton 
Deployment  Plan,  1988,  p.  22) 

Further  TEDSS  "computer  system  is  [utilizes]  TEMPEST  equipment."  However  some 
hardware  that  TEDSS  operates  on  does  not  appear  to  be  TEMPEST  certified,  specifically 
the  color  VGA  monitor.  It  is  also  unclear  whether  TEDSS  is  required  to  follow 
Department  of  Defense  (DoD)  standards  and  comply  with  DoD  Instruction  5200.28, 
Trusted  Computing  Systems  Evaluation  Criteria,  informally  called  the  ’Orange  Book,’  by 
maintaining  a  specified  security  level.  If  TEDSS  must  meet  specific  security  levels,  this 
fact  will  drive  many  system  choices  and  limit  the  ability  to  choose  the  best  platform  to 
support  the  EMT  with  commercially  available  hardware  or  software.  For  example,  if 
TEDSS  must  comply  with  TEMPEST  electronic  emissions  requirements,  the  number  of 
portable  computers  which  can  serve  as  TEDSS  platforms  will  be  reduced  dramatically 
whereas  some  storage  technologies  such  as  CD-ROM  may  be  eliminated  altogether  from 
consideration. 
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G.  SUMMARY 


This  chapter  has  addressed  major  software  issues  that  will  affect  TEDSS  n  initial 
and  future  usability.  These  include:  NCS  goals,  long-term  system  growth,  useability  and 
adaptability,  system  maintenance,  database  administration,  operating  system  capabilities, 
system  stability,  and  security  requirements.  The  following  chapter  will  address  TEDSS’ 
unique  hardware  requirements  and  emerging  technology  that  may  prove  relevant  to 
TEDSS  n. 


0 


4. 
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VI.  OPERATIONAL  CONSTRAINTS  IN  HARDWARE  DEVELOPMENT 

Telecommunications  Emergency  Decision  Support  System  (TEDSS)  operational 

i 

I 

constraints  restrict  the  hardware  options  available  to  assist  the  Emergency  Management 

Team  (EMT).  The  present  deployable  hardware  is  still  usable,  but  it  will  not  provide  the  «  i 

support  required  to  fully  utilize  the  proposed  system. 

TEDSS  initial  requirement  for  portability  is  not  expected  to  change,  but  the  method 
of  satisfying  this  requirement  should  be  decided  primarily  on  management  rather  than 
technical  grounds.  The  National  Communications  System  (NCS)  and  the  EMT  must 
decide  what  mix  of  computing  power  and  flexibility  is  desired  to  satisfy  TEDSS  hardware 
requirements. 

The  movement  of  TEDSS  from  a  textual  orientation  to  a  Gr^hical  User  Interface 
(GUI)  will  "involve  a  complete  re-assessment  of  your  system  and  your  needs.  Every 
item,  from  the  hard  disk  drive  to  the  display,  will  be  affected  by  the  change." 

(Nicholls,  1990,  p.l64).  Sp>ecifically  TEDSS  current  internal  gas-plasma  monitor  will  not 
provide  the  high  quality  resolution  needed  in  a  GUI.  TEDSS  II’s  increased  use  of 
graphics  will  require  better  video  displays,  increased  data  storage  requirements,  and 
alternate  mput  devices. 

The  following  sections  discuss  the  specific  hardware  issues  related  to  the  proposed 
TEDSS  n  and  technologies  that  may  offer  future  enhancement  piossibilities.  ■* 


64 


A.  PORTABILITY 


The  most  powerful  platform  in  terms  of  computing  power,  graphics  capability,  and 
future  expendability  is  a  workstation  with  an  external  large  screen  color  monitor. 
However  this  power  comes  at  the  expense  of  a  simple  fly-away  package  that  could  be 
transported  by  the  EMT. 

TEDSS  primary  mission  to  assist  in  emergencies  requires  that  it  be  portable. 
However,  the  requirement  for  portability  may  be  satisfied  by  several  methods.  The 
current  TEDSS  system  is  portable,  but  requires  the  relocation  of  three  separate  items; 
computer,  external  hard  disk,  and  external  monitor.  The  inability  to  move  TEDSS  as  a 
single  unit  could  be  a  deterrent  to  the  efficient  transportation  of  TEDSS  and  the 
mobilization  of  the  EMT. 

Commercial  portable  computers  may  be  categorized  as  either  luggable  or  laptop. 
Luggable  computers  are  self-contained  with  all  components  including  the  central 
processing  unit,  secondary  storage  devices  and  display,  in  one  container  which  requires 
an  external  power  supply  to  operate.  The  existing  TEDSS  Compaq  Computer  is  an 
example  of  a  luggable  machine.  A  laptop  computer  provides  the  same  functionality  as 
the  luggable,  except  with  a  physically  smaller  container  and  an  internal  power  source. 

Luggable  computers,  because  of  their  larger  size  and  reduced  concern  for  power 
consumption  and  space,  often  provide  more  powerful  and  ceqrable  computers  than  laptops. 
Additionally  a  luggable  will  allow  a  wider  selection  of  other  vendors’  hardware 
components  which  can  be  integrated.  Portable  computers  often  contain  the  same 
components  as  a  conventional  personal  computers  (PC),  however  the  efficient  integration 
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of  components  and  utilization  of  space  result  in  a  smaller  footprint.  Additionally  video 
displays  and  keyboards  will  often  be  somewhat  smaller  and  optimized  for  the  specific 
portable  computer. 

L^top  computers’  primary  advantage  is  their  reliance  on  internal  power  sources. 
While  their  internal  batteries  normally  do  not  last  longer  than  three  hours,  they  free  the 
user  from  the  confines  of  a  conventional  office  setting.  Laptop  computers  generally 
weigh  less  than  fifteen  pounds  and  will  contain  the  equivalent  components  as  the 
luggable;  however,  they  have  all  been  optimized  to  decrease  power  consumption,  space 
and  weight  requirements.  Nearly  all  commercially  available  laptop  computers  use  a 
Liquid  Crystal  Display  (LCD).  LCD  monitors  are  noticeably  inferior  in  screen  quality, 
size  and  update  speed  to  most  other  types  of  monitors.  However,  the  LCD’s  small  power 
consumption  makes  them  the  only  display  type  that  can  be  supported  by  battery  power 
for  extended  periods.  Laptop  computers  have  also  optimized  the  keyboard  to  decrease 
its  size  with  the  result  that  a  similar  number  of  keys  are  fitted  into  less  space  and  in 
different  arrangements  from  conventional  computer  keyboards.  This  may  require  some 
user  adjustment. 

It  is  generally  a  management,  rather  than  a  technical  decision,  whether  the  system 
should  be  AC  powered  or  battery  operated.  Externally  powered  systems  provide 
increased  computing  power  which  must  be  balanced  against  the  need  for  ease  in 
transportation.  Additionally  the  total  size  of  the  unit  must  be  addressed  as  well  as  its 
suitability  to  the  crisis  environment.  Commercially  available  computer  hardware  can 
currently  support  TEDSS  II  regardless  of  the  method  selected  to  achieve  portability. 
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Laptop  computers  will  provide  maximum  utility  to  the  EMT  by  allowing  the  system  to 
be  used  in  any  location  and  without  being  constrained  by  AC  power  sources.  However 
most  laptops  do  not  offer  any  internal  expansion  slots  other  than  that  for  a  modem. 

The  NCS  should  evaluate  its  operational  requirements  with  respect  to  how  TEDSS 
will  be  utilized.  Unless  the  environment  for  TEDSS  is  expected  to  change  dramatically, 
a  luggable  computer  will  most  likely  provide  improved  support  for  future  hardware 
growth.  However,  industry  continues  to  release  more  powerful  portable  computers  so  it 
may  soon  be  possible  to  find  a  laptop  computer  that  supports  many  expansion 
opportunities. 

B.  VIDEO  ISSUES 

Using  a  GUI  is  much  more  demanding  on  the  video  section  of  the  computer  than 
on  most  other  portions  of  the  hardware.  GUIs  facilitate  information  transfer  primarily 
through  graphical  icons,  buttons,  graphs  and  other  visual  cues.  As  the  GUI  screen  will 
normally  be  displaying  several  items  simultaneously,  a  GUI  requires  high  resolution  and 
better  quality  monitors  with  a  larger  physical  viewing  area  to  permit  easier  viewing. 
Grey-scale  monitors,  found  in  most  laptop  computers,  will  support  GUIs  but  the 
additional  use  of  color  may  improve  the  GUI’s  usefulness. 

1.  Color 

TEDSS  will  be  more  effective  with  color.  Color  increases  the  power  of 
information  presentation,  but  it  is  expensive  and,  at  present,  there  is  a  limited  selec  tion 
of  available  color  hardware  options.  While  TEDSS  n  software  could  function  using  a 


67 


monochrome  or  grey-scale  video  display,  the  use  of  color  will  provide  additional 
information  to  the  EMT.  For  example,  a  grey-scale  monitor  would  not  be  able  to  alert 
the  user  as  effectively  with  blinking  messages,  since  sharp  contrast  is  not  currently 
possible  as  with  color  monitors. 

Few  laptop  computers  are  available  with  color  LCD  or  other  type  color 
displays.  So  far  no  technology  has  been  developed  to  make  a  commercial  color  LCD 
monitor  with  acceptable  power  consumption.  Presently,  those  portable  computers  with 
color  monitors  require  an  external  AC  power  source. 

2.  Video  Resolution,  Screen  Size  and  Performance 

GUIs  are  best  suited  to  large  video  monitors,  and  will  tax  the  ability  of  the 
video  portion  to  support  objects  being  moved  on  the  screen.  Because  GUIs  allow 
multiple  events  to  be  happening  concurrently,  the  monitor  screen  or  ’desktop’  tends  to 
become  crowded.  As  in  the  office  environment,  if  the  screen  becomes  too  crowded, 
worker  performance  will  decline.  The  primary  method  of  compensating  for  this  effect  in 
a  GUI  is  to  use  higher  screen  resolution  and  a  physically  larger  monitor.  However  as  the 
screen  size,  or  resolution,  increases,  the  amount  of  information  that  must  be  updated  and 
managed  by  the  video  portion  increases  as  well.  If  no  additional  hardware  is  added,  the 
overall  video  performance  will  deteriorate  noticeably. 

TEDSS  current  VGA  monitor  operates  at  640  by  480  pixels  resolution,  which  * 

is  the  highest  resolution  level  supported  by  most  portable  computers.  This  resolution,  * 

while  acceptable  for  a  GUI  with  one  application  or  window,  may  be  found  lacking  after 
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users  become  more  comfortable  with  the  GUI  and  have  multiple  windows  crowding  the 


screen. 

The  maximum  resolution  of  a  GUI  is  constrained  by  the  hardware  and  video 
drivers  rather  than  the  GUI.  For  example  X-Windows  normally  operates  on  1280  by 
1024  pixel  monitors,  and  the  Macintosh  operates  on  comparable  resolutions.  While 
higher  resolution  increases  the  amount  of  information  which  can  be  displayed,  the  relative 
size  of  the  information  is  decreased,  forcing  a  tradeoff  between  eye  strain  and  amount  of 
information.  The  only  way  to  compensate  for  the  size  reduction  of  information  is  to 
physically  increase  the  size  of  the  screen. 

When  given  a  choice,  users  will  normally  prefer  a  larger  monitor,  but  if 
TEDSS  must  exist  as  a  single  unit  for  ease  in  deployment,  the  user  interface  must  suffer. 
Laptop  computers,  and  many  luggables,  use  a  nine  inch  video  screen  as  measured 
diagonally,  whereas  most  office  computers  use  a  thirteen  or  fourteen  inch  screen. 
However,  graphic  workstations  will  often  use  a  nineteen  inch  monitor.  TEDSS  needs  to 
consider  alternatives  to  support  other  video  systems  than  the  one  supplied  with  portable 
unit. 

LCD  monitors  in  laptop  computers,  while  normally  acceptable  for  word 
processing  and  routine  computer  operations,  may  prove  to  be  unacceptably  slow  and  hard 
to  view  when  using  a  GUI  in  TEDSS.  The  LCD  method  of  lighting  the  screen  results  in 
slower  screen  updates,  and  is  susceptible  to  contrast  problems.  For  current  LCD  displays, 
"the  response  time  (about  250  milliseconds)  ...  is  not  fast  enough  to  display  moving 
images  on  the  screen."  (Baron,  1991,  p.  234).  Tasks  such  as  using  pointing  devices  and 
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scrolling  windows  will  be  slowed  by  the  screen  update  speed.  The  majority  of  LCDs  use 
a  "passive  matrix  design"  which  derive  their  power  savings  by  lighting  only  the  screen 
pixels  that  are  required  to  show  the  letter  or  image.  Because  all  pixels  are  not  activated, 
unlike  CRT  monitors,  l^tops  are  susceptible  to  glare  and  contrast  problems  which  further 
aggravate  the  difficulty  in  viewing  moving  objects  on  the  screen. 

3.  Video  Considerations 

The  quality  of  TEDSS  video  portion  is  critical  to  the  effective  use  of  a  GUI, 
but  if  the  system  is  not  conducive  to  rapid  relocation,  the  EMT  may  not  be  able  to  move 
the  system  quickly  enough.  The  opposing  requirements  of  a  large  screen  which  is 
portable  will  be  difficult  to  attain  with  today’s  technology.  A  middle  ground  must  be 
reached  to  identify  which  requirement  deserves  more  weight.  An  alternative  to  meet  both 
requirements  is  installing  hardware  which  will  support  two  different  monitors,  one  small 
monitor  in  the  portable  for  immediate  deployment,  and  a  larger  monitor  which  is  deployed 
as  soon  as  practical  to  the  EMT.  This  option  requires  other  hardware  and  software  to 
support  the  use  of  different  monitors.  The  portable  computer  must  support  an  external 
video  cormection  or  allow  an  additional  video  card  to  be  installed  to  drive  the  external 
monitor. 

C.  EMERGING  TECHNOLOGIES 

TEDSS  should  facilitate  the  addition  of  new  technologies  as  ^propriate.  The 
emergency  management  environment  is  rapidly  changing  and  tlie  technology  to  support 
it  will  change  also.  Many  commercial  products  in  use  today  were  not  even  imagined  five 
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or  ten  years  ago,  and  there  is  no  reason  to  expect  this  to  change.  TEDSS  should  be  in 
position  to  use  other  technology  such  as  compact  disk  read-only  memory  (CD-ROM), 
write  once  read  many  (WORM)  optical  disks,  hypertext,  and  other  products  that  are 
evolving  from  the  laboratory  to  the  market  place.  Other  existing  office  automation 
products  such  as  networking,  e-mail  and  voice  mail  support  may  become  prudent 
additions  to  TEDSS  as  users  become  more  sophisticated.  To  support  the  ability  of 
TEDSS  to  evolve,  initial  components  selected  for  TEDSS  n  should  not  lead  to  binding 
vendor  relationships,  but  rather  should  rely  as  much  as  possible  on  open  hardware  and 
software  standards. 

CD-ROM  and  WORM  drive  technology  provide  the  ability  to  store  and  retrieve 
hundreds  of  megabytes  of  storage  in  a  medium  that  is  only  a  few  square  inches  ins  size 
and  a  few  ounces  in  weight.  TEDSS  may  be  able  to  use  CD-ROM  to  store  all  relevant 
emergency  action  documentation  (EAD),  maps,  network  operating  manuals,  and  other 
voluminous  information  currently  stored  in  paper  form.  By  using  hypertext  or  other 
methods  to  facilitate  rapid  retrieval,  TEDSS  could  provide  a  ready  emergency  reference 
library  for  the  EMT. 

Technologies  that  are  in  widespread  use  in  office  automation  may  fill  important 
roles  in  TEDSS.  If  update  and  maintenance  of  data  by  the  EMT  becomes  a  bottleneck, 
a  simple  local  area  network  to  allow  another  user  to  remotely  enter  data  in  the  command 
center  may  be  an  option.  TEDSS  could  also  provide  increased  telecommunications 
support  for  the  EMT  to  include  message  transmission,  storing  and  retrieving  electronic 
mail,  and  other  ’normal’  office  automation  tasks. 
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D.  OTHER  HARDWARE  ISSUES 

This  thesis  addressed  many  of  the  major  hardware  and  software  issues  relating  to 
the  redesign  and  update  of  TEDSS,  however  there  are  additional  hardware  issues  that 
should  be  considered  such  as  data  security,  electronic  emissions,  pointing  devices,  and 
output  devices. 

Security  requirements  should  be  defined  early  in  the  TEDSS  n  redesign.  Effective 
security  is  difficult  to  implement  in  a  new  program;  it  approaches  a  herculean  task  to 
implement  after  a  system  has  been  fielded.  If  TEDSS  must  meet  TEMPEST  or  other 
security  standards,  this  wUl  most  likely  be  the  controlling  factor  in  hardware  procurement. 

GUIs  rely  heavily  upon  pointing  devices.  While  most  references  have  been  to  using 
a  mouse  as  the  pointing  device,  other  vehicles  may  be  better  suited  to  the  work 
environment  of  TEDSS.  A  trackball  utilizes  less  space  than  a  conventional  mouse,  while 
a  pen  or  tablet  system  to  enter  information  may  be  more  natural  to  the  users.  Countless 
other  pointing  devices  could  be  used  effectively  with  TEDSS  as  well.  Once  a  pointing 
device  is  chosen,  it  should  be  standardized  across  the  TEDSS  implementation  to  prevent 
confronting  the  EMT  with  different  devices  in  different  regions. 

Several  different  methods  of  data  input  and  retrieval  have  been  addressed,  however 
there  has  been  no  discussion  of  output  devices.  TEDSS  would  appear  to  have  limited 
paper  or  hardcopy  requirements  but  still  should  allow  for  the  output  of  maps  or  text. 
Several  small  portable  printers  using  bubble  jet  or  impact  printing  methods  provide 
acceptable  output  as  well  as  portability.  To  augment  any  output  devices  which  the  EMT 
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deploys  with  TEDSS,  the  portable  computer  should  be  able  to  utilize  laser  printers  and 
plotters  that  may  be  available  at  the  control  center. 


r 
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Vn.  RECOMMENDATIGNS/CONCLUSIONS 
The  goal  of  this  thesis  has  been  to  assess  the  current  state  of  Telecommunications 
Emergency  Decision  Support  System  (TEDSS),  develop  a  vision  for  allowing  TEDSS  to 
better  support  emergency  decision  making  by  the  Emergency  Management  Team  (EMT), 
and  to  assess  the  major  technological  issues  that  should  be  considered  in  implementing 
this  revised  concept. 

TEDSS  is  in  a  critical  time  period  in  its  system  life.  The  current  system  marginally 
supports  the  EMT’s  information  management  requirements,  and  does  not  significantly 
assist  the  EMT  in  effective  decision  making.  To  correct  this  deficiency,  two  paths  may 
be  taken: 

1 .  attempt  to  modify  or  improve  incrementally  upon  the  existing  TEDSS  design,  or 

2.  utilize  the  knowledge  gained  from  the  last  eight  years  of  TEDSS  and  develop  a  new 
conceptual  paradigm  for  assisting  the  EMT. 

Choosing  either  path  requires  the  knowledge  and  understanding  of  the  NCS  objectives  for 
TEDSS. 

One  of  the  serious  problems  in  undertaking  a  redesign  of  TEDSS  is  that  there  is  no 
specific  set  of  requirements  specifications  which  have  been  developed  and  documented. 
Since  TEDSS  can  lot  fulfill  all  roles  equally  well,  the  exact  system  goals  must  be 
determined.  This  thesis  has  attempted  to  provide  a  conceptual  basis  for  a  revised  system 
without  a  complete  knowledge  of  these  objectives.  At  present  there  are  no  known  clear 
cut  goals  of  TEDSS  beyond  improving  the  emergency  decision  making  process.  Since 
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I  have  not  b^en  privy  to  a  full  utilization  session  with  TEDSS  because  of  security 
restrictions,  it  is  important  to  note  that  these  recommendations  must  be  evaluated  with 
early  and  consistent  user  involvement  to  ensure  a  viable  and  useful  product  is  developed. 

It  is  recommended  that  the  TEDSS  orientation  be  shifted  from  textual  to  graphical 
using  the  Tactical  Decision  Aid  (TDA)  concept.  Graphical  presentations  will  assist  the 
EMT  in  rapidly  assimilating  changing  information.  The  TDA  recognizes  that  information 
about  the  decision  environment  is  constantly  changing  and  assists  the  user  in 
compensating  for  this  dynamic  situation  by  allowing  simulations  that  provide  projections 
of  the  results  of  decisions.  The  new  model  of  TEDSS  n  changes  the  system  from  a  data 
base  oriented  system  to  a  graphics  system  in  which  the  user’s  primary  communication 
method  is  the  moving  and  modification  of  graphical  images  rather  than  text. 

The  primary  TEDSS  n  interface  will  be  a  graphical  user  interface  (GUI)  coupled 
with  a  geographic  information  system  (GIS).  Data  will  still  be  stored  in  a  data  base,  but 
its  retrieval  and  query  generation  win  be  done  through  menu  selections  and  highlighting 
of  map  areas.  TEDSS  U  will  use  the  EMT  conceptual  model  of  the  emergency  area  by 
displaying  information  on  maps  with  the  use  of  colorations  and  icons  to  increase 
information  transferal  and  represent  spatial  relationships. 

It  is  recognized  that  TEDSS  cannot  anticipate  or  facilitate  every  decision,  therefore 
the  user  should  be  allowed  access  to  data  through  a  Structured  Query  Language  (SQL) 
interface  to  the  data  base.  This  accommodates  ad  hoc  queries  which  TEDSS  currently 
does  not  support  directly. 
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The  framework  outlined  for  TEDSS  11  will  support  many  implementation  options-. 
By  using  a  GUI  as  the  primary  user  interface,  training  should  be  enhanced  by  providing 
standard  a  menu  structure.  Additional  components  may  be  added  without  a  commensurate 
increase  in  training.  Support  for  missions  such  as  hurricane,  earthquake  and  other  natural 
disasters  affecting  communications  systems  may  be  facilitated  by  additional  damage 
assessment  models  to  augment  the  present  nuclear  model.  Previous  efforts  on  the  Expert 
Telecommunications  Resource  Allocation  Model  (XTRAM)  could  also  be  incorporated 
into  the  model  base. 

TEDSS  should  be  considered  as  a  prototype  which  is  subject  to  continuous 
development  and  change  to  support  the  dynamic  decision  environment  in  which  it 
operates.  To  facilitate  that  goal  of  adapting  to  change,  extra  attention  must  be  placed  on 
the  requirement  assessment  phases  during  initial  and  future  upgrades.  The  EMT  is  a 
skilled,  interested  core  of  users  that  will  ultimately  determine  the  final  utility  of  TEDSS 
II.  Methodologies  such  as  storyboarding  to  map  out  the  current  and  future  requirements 
of  TEDSS,  will  assist  in  validating  and  verifying  requirements  during  development  as  well 
as  to  identify  system  deficiencies  early  in  the  process. 

The  quality  of  decision  support  provided  by  TEDSS  will  ultimately  be  decided  by 
the  quality,  relevance  and  accuracy  of  information  in  the  form  of  data  and  models  which 
it  can  access.  The  dependence  of  TEDSS  on  external  sources  of  information  is  unlikely 
to  change,  but  the  access  to  external  data  sources  should  be  defined.  Use  of  proprietary 
commercial  carrier  information  would  undoubtedly  increase  the  quality  of  support  given 
by  TEDSS,  while  its  absence  will  be  detrimental. 
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The  concept  of  TEDSS  as  a  TDA  is  more  in  keeping  with  the  true  mission  of  the 
NCS  and  its  role  of  emergency  management.  A  TDA-based  information  system  has 
architectural  and  design  ramifications  which  differ  dramatically  from  the  current  database- 
oriented  concept  of  TEDSS. 

The  emphasis  on  graphics  will  tax  TEDSS  hardware  differently.  The  GUI  and  GIS 
require  a  powerful  video  display  system  to  facilitate  the  graphical  presentation  of  data. 
The  GUI’s  ability  to  use  several  system  resources  in  separate  windows  requires  TEDSS 
to  support  multi-tasking.  While  the  GUI  frees  the  user  to  explore  different  screen 
arrangements,  it  also  requires  that  TEDSS  applications  be  implemented  in  conformance 
with  GUI  conventions  to  prevent  reducing  the  GUI’s  overall  effectiveness. 

Furthermore  TEDSS  II  will  ultimately  alter  the  EMT’s  basic  use  of  TEDSS  by 
moving  from  a  text  interface  to  an  interface  using  graphics,  pointing  devices,  and  voice. 
As  the  system  and  the  users  mature,  TEDSS  11  should  become  an  increasingly  powerful 
decision  aid  which  can  enhance  the  ability  to  make  quality  decisions  in  a  multitude  of 
emergency  enviromnents. 
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